Over my whole programming experience, I've gone back and forth on the question of object-oriented programming [medium.com], yay or nay. In this last year, though, I've finally settled conclusively in the nay column, and this is my attempt to articulate exactly why.
...
Object-Oriented Programming is supposed to help us manage state and model problems in terms of familiar objects, but it turns out to be really, really easy to put behaviors in the wrong objects and thereby produce Frankenstein entities that make no natural sense. We quickly end up with unnecessarily complicated and confusing code that actually exacerbates the proliferation of state and promiscuous state sharing (e.g. a Message wants to send itself, so now a Message needs a reference to a Connection object that it otherwise wouldn't need).
...
For years, I took it on authority that Object-Oriented Programming was The Right Way to code, even though I had the constant sense that every class and method I wrote was creating problems for myself down the line, that every possible object decomposition was at best arguable and would eventually need restructuring. Fitting every problem into the mold of classes felt like playing a fool’s game with no right answers.Now that I've stopped chasing the chimera of ‘proper’ object decomposition, I’m much happier and more productive. Of course, in procedural programming, there is no one way to properly decompose a solution either. But with procedural programming, I no longer feel like I’m adding a layer of structure that provides no benefits yet adds complications and confusion to my code.
Do you agree?