It's time to get away from OOP
OOP is considered the largest diamond in the crown of computer science. The best way to organize your code. The solution to all problems. The only sure way to write our programs. The God of programming sent us from above ... Only here the OOP programmer is forced to rake a bunch of all kinds of abstractions, keep track of all shared objects, remember tons of "programming patterns" - and spend their time and energy on all this instead of solving the problem itself.
Many have long criticized OOP, and there are many highly respected programmers among these critics. And even Alan Kay - the inventor of OOP is in their ranks!
The main goal of any developer is to write reliable code. If the code is buggy and doesn't work as intended, then nothing else matters. What's the best way to write reliable code? Keep the code simple. Simplicity is the opposite of complexity . It follows that the developer's primary goal is to reduce the complexity of the code.
Disclaimer:
I'm not an OOP fan, so it's no surprise that this article will seem biased to many. However, I will give arguments in defense of my position.
I also understand very well that criticism of OOP is very painful for many. So many readers will feel offended personally. However, I intend to state what I believe to be correct. For my goal is not to offend, but to point out the problems that OOP has. I am not criticizing Alan Kay
's OOP . He is generally a genius. Personally, I would like OOP to be exactly what Alan Kay intended. What I criticize is OOP in a C # or Java implementation.
The problem is that OOP has long been considered the standard for organizing software code. And so many people think, including those who hold serious positions in the software industry, which is why other approaches to programming are not even considered in most companies.
I had to overcome a lot of difficulties when I wrote in OOP languages. And I have always wondered why these difficulties arose. Maybe I wasn’t too good? Maybe I needed to learn a couple of dozen more "programming patterns"? In the end, I just didn't have the strength left for all this.
This article will tell you how I went from OOP to functional programming over a decade. Since then, I don’t remember a case that I came across a project for which OOP would be best suited. Moreover, projects where OOP was used failed under the weight of the complexity of the code - from some point it was impossible to further maintain and develop them.
TLDR
"Object-oriented programs are the alternative to the right programs."
Edsger W. Dijkstra, computer science pioneer
The goal of OOP was one - to deal with the complexity of procedural code. In other words, OOP was designed to improve code organization. But since then there has been no evidence that OOP is better than the old procedural programming.
The harsh truth is that OOP didn't do the one thing it was designed to do. Everything looked great on paper - we had strict hierarchies of animals, dogs, people ... (And, of course, shapes: rectangles, squares and circles - where can we go without them!) But as the complexity of the application code increased, OOP did not help to reduce it , but on the contrary increased - with tons of necessary "programming patterns" and making it difficult for the programmer to keep track of where and how the values of variables change. OOP made many commonly used procedures, such as refactoring and testing, unnecessarily complex.
Many people disagree with me, but the fact is that the design of OOP in C # or Java was not scientifically thought out, it was not the result of serious scientific research. Unlike functional programming, for example, in Haskell, where lambda calculus is a solid theoretical basis. OOP is not based on anything like that.
In small projects, OOP performs quite well. But what happens when the project grows? OOP is a time bomb that will inevitably explode when the project code reaches a certain size. Projects start to lag, deadlines fail, developers run out of energy, and adding new features becomes almost impossible. In the end, companies are forced to mark such code as "obsolete" and force developers to rewrite.
OOP doesn't fit very well with the way our brains think. We are used to focusing on action: going for a walk, talking to a friend, eating pizza. Our brain has evolved towards "doing something", and not towards building a complex hierarchy of abstract objects.
OOP code is non-deterministic (unlike functional programming): we cannot be sure that with the same input data, we will get the same result every time. This makes it very difficult to understand how the program works. Here's a simple example: compare 2 + 2 and calculator.Add (2, 2) . The last expression, in theory, should always return 4, but it can return 5, 3, or even 1004, because the dependencies of the Calculator object can change his behavior in the most unpredictable ways.