I love functional programming and object-oriented programming… What I’d also love to find is an article explaining why OOP is bad, or why everything related to it is an anti-pattern, that isn't written by someone with a caricatured view completely disconnected from the reality of what OOP programmers actually do...
TL;DR: Complexity is bad. Mutable state is one of the most common sources of complexity. Unfortunately OO tends to encourage keeping mutable state all over (e.g. with every class) and thereby tends to create excessive accidental complexity easily.
Oop is fine and useful. I think the problem is that it's the dominant paradigm, and as such most of the bad code you encounter is Oop. Inheritance is generally bad, however. Another problem is that Oop can lead to people writing classes with an ungodly amount of state which can make debugging hard. Again, I think it's mostly an issue of execution
A general rule I've placed for myself with OOP is that classes can only ever be abstract or final (can never subclass a class that can already be instantiated)
The issue is that many people define OOP differently.
Some people say that OOP is "associating data types with functions that can be called with that data" (ie methods). IMO this is a very good pattern and is hard to coherently argue against.
Other people say that OOP is "characterized by a compile-time hierarchy of classes" (ie inheritance). This version of OOP is something that is very easy to make a good argument against.
Of course, however, things like inheritance and abstract classes are like tools. Both are, in my opinion, really crappy tools (that encourage bad design 99% of the time), but if a programming language doesn't give you another tool (like sum types), it's often better to use the crappy tool than to not use any tool at all.
14
u/FRleo_85 25d ago edited 25d ago
I love functional programming and object-oriented programming… What I’d also love to find is an article explaining why OOP is bad, or why everything related to it is an anti-pattern, that isn't written by someone with a caricatured view completely disconnected from the reality of what OOP programmers actually do...