Episode 1 – Robert C. Martin

Could you also announce any new videos on your blog, and syndicate it through planet.clojure ?

This will keep most of the clojure community informed.

Thanks for amazing effort !

I have transcribed the part from 41:00 to 43:37, where Uncle Bob discusses OO and immutability. This part corresponds to “Functional Programming and Object Oriented Compatibility” in the Topics list on this page.

Proctor: So I know you still go out and preach for good object-oriented design.

Bob: Sure.

Proctor: And one cannot blame you. How has your message changed when you reach out to the developers doing object-oriented programming?

Bob: I don’t know that it’s changed at all. If we’re doing OO, we have a set of principles that we need to follow, we need to write good code, we need to develop systems that are decoupled, and plugins with a plugin architecture – all of that stuff I believe remains the same.

FP does not change what OO is. There has been a fair bit of discussion over whether or not OO and functional are even compatible. And I find that very interesting, because, from my point of view, they are completely compatible. And orthogonal. They have almost nothing to do with each other. A program can be both OO and functional simultaneously.

The reason people get confused about that is that they think of objects being inherently mutable. But there’s nothing about an object that requires it to be mutable. You can operate on an object, and its return value can be another object, rather than a mutation of the existing code. Which means you can write very reasonable object-oriented programs in a functional style.

One of the benefits of the OO style is polymorphism – the ability to invoke a function and not know precisely what function is going to be invoked. There’s this very interesting inversion of dependencies that occurs across a polymorphic boundary. And that inversion of dependencies can still exist in a functional language.

Example: Clojure has a facility called protocols, and records, where you’re allowed to create these – they look like methods. They look like method declarations. And then they can be implemented by a separate module entirely, with the same kind of dependency inversion structure. So you get all the benefit of polymorphic OO – all the same principles apply, as far as that’s concerned – and you can also insert immutability. And get a decent, functional, object-oriented program. Which is structured, too, by the way.