Exactly. I never got into OOP design patterns and my co-workers could not convince me this is a good idea. I thought for a while that I am crazy but then I got to know Erlang and Clojure. Joe and Rich set me straight on software design.
>> Keeping code simple is not easy. It takes a lot of trials and errors to know what works and what doesn’t.
Refactoring helps. I usually achieve 20-40% reduction with the first refactoring.
Even OOP has its place. I once wrote a simulation of a physical system with a lot of moving parts and OOP made the problem tractable and the code readable and maintainable. I don't think any other style of coding would have had such an enlightening effect on that particular problem.
Lots of mechanical linkages interacting with each other. Move one and everything else moves as well. Gears, shafts, levers, chains (modeled as independent links), that sort of thing.
While it might just look like word soup from that particular vantage point I'd venture to say that Spring Framework is one of the most successful examples of OOP in history. It has massive adoption because of its sheer flexibility which all of those abstract generator factories give it.
Granted, I think Ruby on Rails is also an amazing project. For slightly different reasons, but then again, they're different use cases serving different paradigms and different groups of people.
It isn't the paradigm that makes something good or bad or better or worse. It's the quality of the implementation.
Sorry I am not trying to turn this into a framework discussion. I just used that list the exhibit the sort of naming that I do not really like. I like if I can tell what my code does. I usually use verbs in naming methods create, update, delete, add, remove, run, wait, etc. and try to name the classes (or more likely just packages, modules) after what they do.
Regarding your comment about the quality of implementation, I agree. This is why I like paradigms that are simple enough for everybody to understand.
>> Keeping code simple is not easy. It takes a lot of trials and errors to know what works and what doesn’t.
Refactoring helps. I usually achieve 20-40% reduction with the first refactoring.