It sounds like you're talking about over-engineered code, not "good code". When people solve problems that aren't there, or prematurely optimize, or make soluti

It sounds like you're talking about over-engineered code, not "good code". When people solve problems that aren't there, or prematurely optimize, or make solutions needlessly general at the expense of readability, they're making the code worse. Code is like regulation. Everyone agrees that we need laws and regulations, and that some complexity is needed to get it right, but a 7500-page code is strictly worse than a 25-page code that achieves the same end. OOP is an interesting paradigm. The original vision of it (seen in Smalltalk, Ruby, and with a completely different approach, Scala) was a middle ground between imperative and functional programming that can capitalize on the benefits of each, and that looked a lot like the message-passing paradigm we see in Erlang. Unfortunately, what's now called OOP is absurd scaffolding and misuse of "design patterns" that makes solutions much more complex than the problems they exist to solve. A major problem occurs when OOP is expected to fill needs better-suited by functional approaches, as in C++ and Java. It's not that OOP is evil. It's that when you start seeing FooFactoryFactory classes, you should really have been using higher-order functions a long time ago.