I am from OO background just started learning FP paradigm. Came across quote by Michael Feathers - "OO makes code understandable by encapsulating moving parts. FP makes code understandable by minimizing moving parts"

What exactly he meant by "moving parts" ? My guess is that by moving parts he meant "state mutation" because FP promotes immutability and thus minimizes state mutation whereas OO does not discourage state mutation but rather encapsulate data (thus encapsulating mutating state of object)

I can feel how pure functions in FP promoting immutability and no side effects can result in better code clarity thus making it more understandable and more declarative vs imperative. Somehow benefits of similar nature is not very apparent to me in OO when mutating state is encapsulated.

For example below adapter object is accessed via public interfaces only but I still feel its state is not encapsulated because each step assumes some sort state transition in previous step and hence execute method looks imperative in nature.

void Execute(IdataAdapter adapter) {

OO definition around encapsulations mainly talks about data hiding and advanatges we get like changing internal data structure w/o breaking clients etc. But I would like to understand it better in context of above statement made by Michael Feathers. My question is basically - By encapsulating mutating state in OO makes code understandable in a same way as FP by minimizing state mutation ?

  • I've always seen moving parts used to mean "independent elements" or "code units", no matter if their state changes or not. A code base with "many moving parts" usually describes a more complex situation but more flexible since you can arrange the parts as you like, while "few moving parts" characterizes a simpler, more monolithic case. – guillaume31 Dec 13 '18 at 12:32

Yes, both are approaches to a common problem.

Software programs necessarily have a lot of parts in order to go from “I have a website that shares cats videos!” (Or whatever) to “I can do a few operations on 1s and 0s!”. Because fundamentally, every program ends up as some basic operations on 1s and 0s.

If you don’t provide any abstractions, if you don’t provide any structure to your programs then they’re huge and inscrutable bunches of big manipulation. Object Oriented programming provides abstraction and structure via objects. Functional programs provide abstraction and structure via functions. And of course each tends to have a little bit of the other as well as some imperative programming for good measure.

But the underlying motivation is the same.


Somehow benefits of similar nature is not very apparent to me in OO when mutating state is encapsulated.

After you make the above comment, you show code where the state is decidedly not encapsulated. Of course you don't see the benefits in that case.

In well written OO code, you will find that the methods of classes are more about telling an object what happened rather than telling it what to do, (viewDidLoad, buttonTapped, serverRespondedWith, etc.)

In the example you show, your function is explicitly telling the adapter what to do, and importantly, the class using the adapter must know the state of the adapter in order to call the methods without error (even if it doesn't explicitly check the state.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.