OOP vs FP

Richard Kenneth Eng
2 min readApr 30, 2017

--

Robert C. Martin (aka “Uncle Bob”) wrote about the OOP vs FP controversy a while back. He explained that at a fundamental level both OOP and FP are about functions that operate on data, so the debate between these two paradigms is rather silly. It borders on religion. Said Uncle Bob:

Objects are not data structures. Objects may use data structures; but the manner in which those data structures are used or contained is hidden. This is why data fields are private. From the outside looking in you cannot see any state. All you can see are functions. Therefore, Objects are about functions, not about state.

When objects are used as data structures it is a design smell; and it always has been. When tools like Hibernate call themselves object-relational mappers, they are incorrect. ORMs don’t map relational data to objects; they map relational data to data structures. Those data structures are not objects.

Objects are bags of functions, not bags of data.

And:

Every functional program ever written is composed of a set of functions that operate on data. Every OO program ever written is composed of a set of functions that operate on data.

It is common for OO programmers to define OO as functions and data bound together. This is true so far as it goes; but then it has always been true irrespective of OO. All programs are functions bound to data.

You might protest and suggest that it is the manner of that binding that matters. But think about it. That’s silly. Is there really so much difference between f(o), o.f(), and (f o)? Are we really saying that the difference is just about the syntax of a function call?

This was further clarified by Dan Grossman of the University of Washington who discussed OOP vs functional decomposition.

OOP and FP are really flip sides of the same coin. Even the much-touted feature of data immutability that FP adherents love to trumpet is not unique to FP. Java, for example, employs many immutable classes/objects.

Immutability is a technique or pattern, not a language feature. It can be applied in any programming language. JavaScript supports immutability through a special library. Smalltalk could support immutability by convention or discipline. That pure FP languages such as Haskell normally prevent mutability by not allowing assignment is neither here nor there. All FP languages must allow mutability in some manner or in some context if you want to get any real work done.

At the end of the day, OOP and FP each have their appropriate use cases. Neither is a panacea. So why are people debating this at all???

--

--