Inheritance, which allows classes to reuse state and methods of other classes.
This is the absolute worst feature of typical OOP languages. I don’t know of any case where it is the best way to solve a problem and very often becomes a nightmare if you don’t get the exact hierarchy of types right. It becomes a nightmare once you have something that does not quite fit into the assumptions you original made when you started out. Which happens all the time.
The examples given with the logger can be solved just as well if not better with interfaces/traits with solutions that don’t have that problem.
Composition is far better and immensely more flexible than inheritance. Extracting duplicate code into helper classes or static functions is a good option.
Conformance to interfaces or protocols with default implementations is a great alternative as well.
I like OOP more than other styles, it’s just often badly done. Complex inheritance, huge classes that do too much, overuse of factories and similar patterns, can ruin it.
I’ve seen some surprisingly fragile OOP solutions that require tons of internal knowledge about how the classes work. It seems to be a popular approach to writing code that just isn’t very flexible.
It requires you model your problem perfectly from the start, then it can work alright. But in reality you cannot know the future and when new requirements come in that don’t fit the model you created you are left in a crappy spot of needing to refactor everything or just cram it in however you can.
Note that I am explicitly calling out inheritance here rather than OOP as a whole. There are many things about OOP that are not that bad or quite ok, like composition for instance. It is generally badly designed inheritance that leads to
require tons of internal knowledge about how the classes work
And it is very hard to create a good inheritance structure that does not devolve over time as new requirements get added. While there are other patterns that OOP languages have started to adopt in more recent years (like composition and interfaces) that solve a lot of the same problems but in a vastly more maintainable way.
is very hard to create a good inheritance structure that does not devolve over time as new requirements get added
That’s such an important point. Whatever else folks take from this thread, I hope they catch that.
And I’ll pile on to add - more layers is more risk. One layer of inheritance is a lot easier to keep maintaining than inheritance that goes four layers deep.
This is the absolute worst feature of typical OOP languages. I don’t know of any case where it is the best way to solve a problem and very often becomes a nightmare if you don’t get the exact hierarchy of types right. It becomes a nightmare once you have something that does not quite fit into the assumptions you original made when you started out. Which happens all the time.
The examples given with the logger can be solved just as well if not better with interfaces/traits with solutions that don’t have that problem.
Composition is far better and immensely more flexible than inheritance. Extracting duplicate code into helper classes or static functions is a good option.
Conformance to interfaces or protocols with default implementations is a great alternative as well.
I like OOP more than other styles, it’s just often badly done. Complex inheritance, huge classes that do too much, overuse of factories and similar patterns, can ruin it.
I’ve seen some surprisingly fragile OOP solutions that require tons of internal knowledge about how the classes work. It seems to be a popular approach to writing code that just isn’t very flexible.
It requires you model your problem perfectly from the start, then it can work alright. But in reality you cannot know the future and when new requirements come in that don’t fit the model you created you are left in a crappy spot of needing to refactor everything or just cram it in however you can.
I recently did some refactoring with injector and composition patterns already there and it was a breeze.
OOP isn’t bad but like anything it requires some care.
Note that I am explicitly calling out inheritance here rather than OOP as a whole. There are many things about OOP that are not that bad or quite ok, like composition for instance. It is generally badly designed inheritance that leads to
And it is very hard to create a good inheritance structure that does not devolve over time as new requirements get added. While there are other patterns that OOP languages have started to adopt in more recent years (like composition and interfaces) that solve a lot of the same problems but in a vastly more maintainable way.
That’s such an important point. Whatever else folks take from this thread, I hope they catch that.
And I’ll pile on to add - more layers is more risk. One layer of inheritance is a lot easier to keep maintaining than inheritance that goes four layers deep.
And if you only have one layer then why not just use interfaces/traits? Which are a vastly better design than inheritance.