Object-oriented programming (OOP*) is not beneficial. This way of writing software often hurts more than helps.
* The mainstream manifestations of OOP as in C++ and Java. I have less distaste for the message-passing, Smalltalk-style implementations.
Object-oriented programming is hard to understand. To a programmer who has dealt with objects over most of their career, objects can seem easy. However, there is a very large vocabulary of knowledge that we have internalized to be effective. For example, the rules of prototypal inheritance and `this` are a lot to learn. The warts of multiple inheritance and obscurities like covariance and contravariance are lost even on senior developers. At scale, object systems become so hard to bear that people turn to code generators to get around object-oriented shortcomings in languages where OOP is a forced paradigm.
Even when you feel comfortable with OOP, the constructs are very often footguns to a good design. There is a buffet of patterns and options to building objects. While flexibility in solving a problem is highly desirable, objects can easily go wrong. Internal state, getter/setter noise, responsibility mismatch, God objects, and flaky hierarchies are some examples. Starting with an object oriented approach is unnecessary. The most important thing about design is making few decisions to allow code to adapt to a changing set of requirements and additions. OOP segments both methods and data across “classes” and these boundaries are painful to work around as a design grows.
It is also important to remember the job at hand. Programmers transform data and read and write to I/O. (You can model human interaction as a very inefficient I/O device as well.) Object oriented design is not a prerequisite to meeting our goals. Over time, we have seen technology shift towards data processing, short transactions, and less stateful code. The idea of a program receiving input (potentially unstructured depending on wire protocol), hydrating that data into class instances, manipulating the instances and performing side-effects, serializing the results for the wire protocol, and then sending output is overly complicated. Service boundaries are important, but we do not need to buy into OOP to achieve those.
I advocate functional programming. The learning curve to functions can be just as high as objects if someone is interested in set or category theory. However as the ideas get harder, the pitfalls are mostly in the readability of the code. Most code is very simple and more complex solutions are a-la-carte. In OOP, you start in the world of pitfalls day one. Over the function-as-value hurtle, we can get things done and grow as we need. We pick the battles we fight.
Functions do not shoehorn a design in the same way picking which methods and values pack into which class does. We can create tons of functions that operate on data which are not coupled to any particular object. We can be much more granular about code reuse beyond the limited public/private modifiers on methods as the functions do not need to coexist with any particular object. This decoupling makes functions more reusable and the creation and deletion of functions carry much less initial cost and long-term overhead.
For the job at hand, working in functions is the most straightforward way to transform data and encapsulate I/O via message passing and dispatch. The use of functions is close to the real task. We see this as more systems are being written with input/output contracts and determinism in mind. As far as service boundaries, functional specifications have proven to be more powerful than object hydration and serialization. Generative and property-based testing where the tests write themselves are at the forefront of functional development.
Thank you for reading.