From time to time I read an “opinion article” (just like this one) of why people think that OOP is very bad for the world and everybody should embrace Functional Programming (e.g. Why is OOP Such a Waste?).
I think people make good points about the issue with OOP, mostly centered around statefulness and what could be called an “un-natural relationship between logic containers in the code”. That leads to bugs and learning complexity.
My opinion is a little bit less extreme. While I can’t say that I’ve worked on a lot of “production” functional code, I’ve tried to read enough of it that it is pretty clear to me that there is a non-trivial challenge on how to actually document and structure functional code. I think there are two key pieces around this:
- The “dynamic compositional nature” of the code, where code can more easily be used across multiple use cases leads to a more “abstract” approach to coding, which is harder to clearly put into words.
- Some activities are much harder to represent without state, leading to developers to do hard-to-read tricks with the code in order to achieve this statelessness required by the approach. It doesn’t necessarily make the code less efficient, just harder to read.
Granted, I’m a big fan of FP. I also agree that makes code safer by default and leads to designs that end up being simpler and more decomposed.
What I don’t agree is to being stuck in this idea that OOP is just terrible, and the abstractions that it enforces are “pure evil”. I think there is value to the types of entities that it generates, the ability that people have to better relate to them, and sometimes the alignment with business relationships (which are often stateful themselves). So I feel like focusing on the bad things is almost like throwing out the baby with the bath water. There are good things about OOP and we should value them.
Probably one day I should revisit this topic with specific examples to share. For now I’ll leave it in this abstract-ish state.