This is a very interesting article.
First of all, I’m not a defender of OOP. If you would prove me now that Functional Programming is better, I would use it. I don’t really care about the tools, the mindset is what matters.
Speaking of mindset, I think you attack the tools (OOP paradigm) and put on it every mistakes people make. But people make these mistakes not because of the tool, but because of the mindset they have.
Unfortunately, OOP provides developers too many tools and choices, without imposing the right kinds of limitations
Some lines below:
When used properly, functions provide…
That’s weird to me. On one side you say that we can do bad things with OOP because it doesn’t limit us, and on the other side you say that we need to use functions properly. We are not that limited either to do a mess with functions at the end, are we?
I have an example: even if I never really tried functional programming (I plan to learn Clojure), I saw functional projects which were total failure: an insane amount of functions, no way to know what data is passed to what function at runtime. Functions calling functions calling functions, till your headache could not follow the twisted flow anymore. Speaking about complexity and headaches, that was a good one.
This is my point: with a wrong mindset, you can use your tool so badly you will go into a total disaster. Now, it is true as well that there are better tool than other. However, I saw successful and complex project with OOP, so I have some doubt that everything in OOP is bad.
Let’s quote your article again:
Unfortunately, the mental juggling of mutable state is at the very core of OOP .
If you want to pass everything by reference, yes it will be. But you don’t have to.
In Functional Programming, state typically is being isolated
Typically? Is it possible that it’s not? Of course it is. Again, a question of mindset.
In OOP, every object has its own state, and when building a program , you have to keep in mind the state of all of the objects that you currently are working with.
Take a lot of data, a lot of behaviors, and you have complexity. If you have an insane amount of complexity, you won’t be able to retain everything. Whatever paradigm you use.
Is all state evil? No, Alan Kay state is not evil! State mutation probably is fine if it is truly isolated (not the “OOP-way” isolated).
To make the code more efficient, objects are passed not by their value, but by their reference. This is where “dependency injection” falls flat.
I think your arguments again encapsulation are pretty weak. You speak a lot about Dependency Injection but, again, objects can be passed by value, not necessarily by reference. Yes, it’s a thing.
While “program to an interface, not to an implementation” is the recommended approach in OOP, not everything should become an interface. We’d have to resort to using interfaces in the entire codebase, for the sole purpose of testability.
You should not understand interface as the interface construct. Interface, in that case, can be a wrapper. I can be anything which protect your data and behavior to leak elsewhere.
“ Yet testing of private methods in OOP is nearly impossible.”
I do it very often. I don’t code in Java though, but OOP is not only Java.
I could continue on and on. Maybe the real debate here is: should we provide freedom to developers, since they should know what they do, or should we limit their freedom?
Another point: it’s easiest to convince people by really showing why FP is good, not why OOP is bad. Convincing with a strong and negative critic is not really effective, in my own experience.
At the end, I think that you target OOP even if you really criticize a lot of wrong habits and mindsets. As with FP, you need to learn how to do properly things, otherwise it won’t work. Give a hammer to a crazy psychopath, and he might kill people with it. Who is responsible: the psychopath, or the hammer?