4 ms·
I feel the same way for OOP paradigm but I found it's usually hard to argue against it because it seems to be so ingrained into people's minds. After all that's
by menaerus 4y ago
I feel the same way for OOP paradigm but I found it's usually hard to argue against it because it seems to be so ingrained into people's minds. After all that's what we are taught in universities and presented as a first go-to toolbox so it's no wonder.
I'm guilty of that defending attitude too but after probably several hundreds kLoC of OOP style and utilization of whatnot design patterns I've came to realization that it's mostly great for overcomplicating stuff for no materializable advantage.
- bluetomcat 4y agoI think the problem is that OOP is mostly taught as a separate paradigm, when it should be seen as a convenience layer over procedural imperative programming. It is about bundling procedures together in groups, associating them with mutable state, and protecting and encapsulating that state from other pieces of code.
- sshine 4y agoI see two big problems with OOP: 1) OOP takes credit for a lot of programming concepts by rebranding them. E.g. abstraction. 2) OOP-specific concepts are either over-used or downright broken. E.g. inheritance, encapsulation.
- menaerus 4y agoYes, I agree, my experience is also that OOP is taught as something orthogonal over procedural imperative programming whereas it should be taught as an extension to it. But even with that said I honestly cannot think of many examples where OOP provides more elegant solution to the problem. Quite the contrary, any larger and more complex OOP-style codebase is quite an unreadable mess despite all the standard promises about the readability, maintainability, "testability", clean abstractions etc. I think that the biggest bend in my mind was when I set myself a goal to try to digest "Elements of Programming" by A. Stepanov and "Modern C++ Design" by A. Alexandrescu. Don't let the "modern" in the title trick you, it's a book from 2001. But irrelevant of the programming language, which in my example happens to be the C++, these two books triggered me to start challenging the tunnel vision I had up until then. It took me some time and a lot of experimentation to basically unlearn the OOP way of approaching the problems and trying to embrace a totally different, I'd say, almost mathematical way of looking at the things. It felt like a relief and it really had a huge impact not only on my code style but the way I think about the problems. Since then I think I started producing much simpler and, what I think, non over-engineered code of better quality without a lot of unnecessary cruft.
- randomdata 4y agoThe bigger problem is that OOP isn't even consistently defined. Kay's (who is oft credited with inventing the term) definition revolves around message passing, which negates the idea of it being a layer over procedural imperative languages as Erlang fits his model of OOP.
- f1shy 4y agoThe problem, I think, is that OOP is teach with lots of inheritance. And people think is all about inheritance, and is the only valid tool. Correctly (sparingly) used is ok, but 99% of the time is over used. That is the "All has to inherit from something" illness. Another thing that is overused is hiding: all has to be private, all accessed through getters/setters, all so deeply hidden as possible... OOP has good ideas, but they have their place. They are way way way to much overused.
- menaerus 4y agoAgreed. OOP is a valid tool and we use tools to solve problems but the moment it becomes a wrong tool to use is when you find yourself trying hard to retrofit the original problem only so that it can match your abstract OOP puzzle. That's just calling for more problems in my experience.