4 ms·

> OOP" done right (aka no inheritance, simply method polymorphism). Why do you consider inheritance a bad feature of OOP?

jimmy1 8y ago
On a very high level, in the vast majority of cases, you bring along lot of baggage, both in code and mental, that you don't need, and compared to some alternatives, such as composition, it is simply far less flexible. Inheritance fits a much smaller subset of problems than people think (one of them is GUI design, a problem inheritance fits with nicely). But like everything in this industry, it tries to get shoe-horned in to solve every problem.
- stevenwoo 8y ago
  It's surprising when I go into interviews and the people interviewing me do not have enough experience working with object oriented code (in the languages I know) to have come to realize this - it's one of those things it seems to have to be relearned over and over.
golergka 8y ago
In my personal experience, overriding non-abstract methods is definetly the worst feature of OOP. Too often comlpex codebases have multi-level overrides, some call base method in the beginning, some call it in the end, and some none at all - and almost always this leads to incoherent contracts and behaviour. Interface-only inheritance and composition instead of inheritance (with components or otherwise) is almost always simpler and thus more error-proof. Even if sometimes you have to repeat yourself a couple times, decrease in mental complexity is definetly worth it.
bluejekyll 8y ago
Think about it as the difference between only inheriting functionality (interfaces in Java 1.8+, Rust traits, etc) vs inheriting data. OOP can become spaghetti very quickly. Especially as people mistakenly allow children to modify parent memory directly, protected non-final fields in Java. Once that happens and as the inheritance higherarchy gets deep, understanding what a field actually is at any point becomes very difficult. Interface and trait inheritance at least removes one piece of confusion by only allowing functions to be inherited, which makes code much easier to reason about.
lmkg 8y ago
Inheritance says that a derived class is a subtype of its base class (this is formalized in the Liskov Substitution Principle). To me, this is strongly coupling two things that don't have a very good reason to be coupled: Code organization and expression substitutability. Sometimes I want to derive a supertype. Sometimes I want to re-use behavior but I don't want the new type to be expression-compatible at all. But inheritance says that if I'm re-using code, I must accept certain expression substitution relationships between my code and the code I'm re-using. As with anything, there are reasons to use it and situations where it makes sense. But it just seems like a very niche connection to use as the basis of a language design.
sethrin 8y ago
Say you decide to make a video game, and you decide to make a couple of classes for your game objects to inherit from. You make the classes Tool and Weapon. You have just prevented yourself from making the game Clue. The solutions to this tend to be ugly, and your object relations will tend to change over time, often in ways that are difficult to reconcile. Thus, GoF suggests to prefer composition instead of inheritance.
- TheArcane 8y ago
  GoF?
  - Wildgoose 8y ago
    The "Gang of Four", the four authors who wrote the classic "Design Patterns" book, (subtitled "elements of re-usable object-oriented software").
  - sethrin 8y ago
    As Wildgoose says, it's a frequently-used initialism for the Design Patterns book, which is otherwise somewhat awkward to refer to concisely and unambiguously.

jimmy1 8y ago

On a very high level, in the vast majority of cases, you bring along lot of baggage, both in code and mental, that you don't need, and compared to some alternatives, such as composition, it is simply far less flexible. Inheritance fits a much smaller subset of problems than people think (one of them is GUI design, a problem inheritance fits with nicely). But like everything in this industry, it tries to get shoe-horned in to solve every problem.

stevenwoo 8y ago
It's surprising when I go into interviews and the people interviewing me do not have enough experience working with object oriented code (in the languages I know) to have come to realize this - it's one of those things it seems to have to be relearned over and over.

golergka 8y ago

In my personal experience, overriding non-abstract methods is definetly the worst feature of OOP. Too often comlpex codebases have multi-level overrides, some call base method in the beginning, some call it in the end, and some none at all - and almost always this leads to incoherent contracts and behaviour. Interface-only inheritance and composition instead of inheritance (with components or otherwise) is almost always simpler and thus more error-proof. Even if sometimes you have to repeat yourself a couple times, decrease in mental complexity is definetly worth it.

bluejekyll 8y ago

Think about it as the difference between only inheriting functionality (interfaces in Java 1.8+, Rust traits, etc) vs inheriting data. OOP can become spaghetti very quickly. Especially as people mistakenly allow children to modify parent memory directly, protected non-final fields in Java. Once that happens and as the inheritance higherarchy gets deep, understanding what a field actually is at any point becomes very difficult. Interface and trait inheritance at least removes one piece of confusion by only allowing functions to be inherited, which makes code much easier to reason about.

lmkg 8y ago

Inheritance says that a derived class is a subtype of its base class (this is formalized in the Liskov Substitution Principle). To me, this is strongly coupling two things that don't have a very good reason to be coupled: Code organization and expression substitutability. Sometimes I want to derive a supertype. Sometimes I want to re-use behavior but I don't want the new type to be expression-compatible at all. But inheritance says that if I'm re-using code, I must accept certain expression substitution relationships between my code and the code I'm re-using. As with anything, there are reasons to use it and situations where it makes sense. But it just seems like a very niche connection to use as the basis of a language design.

sethrin 8y ago

Say you decide to make a video game, and you decide to make a couple of classes for your game objects to inherit from. You make the classes Tool and Weapon. You have just prevented yourself from making the game Clue. The solutions to this tend to be ugly, and your object relations will tend to change over time, often in ways that are difficult to reconcile. Thus, GoF suggests to prefer composition instead of inheritance.

TheArcane 8y ago
GoF?
- Wildgoose 8y ago
  The "Gang of Four", the four authors who wrote the classic "Design Patterns" book, (subtitled "elements of re-usable object-oriented software").
- sethrin 8y ago
  As Wildgoose says, it's a frequently-used initialism for the Design Patterns book, which is otherwise somewhat awkward to refer to concisely and unambiguously.