3 ms·

I respectfully disagree that frameworks and stdlibs for languages like Java and .Net are better due to use of Inheritance. In fact I struggle to come up with a

by zaphar 6y ago

I respectfully disagree that frameworks and stdlibs for languages like Java and .Net are better due to use of Inheritance. In fact I struggle to come up with a single occasion where use of Inheritance was not an Antipattern. The exception I suppose is when you have no other way to do polymorphic interfaces.

donor20 6y ago
I'm no expert, but the mental model of an interface is so simple. The inheritance model I liked in school, but practically the payoff just never seems to show up.
wvenable 6y ago
Lots of things in software development have an is-a relationship. The only time inheritance is an antipattern is when it's used for code-reuse and it isn't modeling an is-a relationship. Once you get to application code there aren't a lot of is-a relationships but inside operating systems, libraries, and frameworks it does come up legitimately.
- zaphar 6y ago
  Is-a relationships are best handled by interfaces. If you don't have those and only have inheritance then that is the exception I mentioned above. In those cases I would argue that the base class should be composed entirely of abstract methods and the depth of the inheritance hierarchy should be no greater than 1.
  - wvenable 6y ago
    If you have something that is something else in almost every way except for one or twos details inheritance is far superior than interfaces. The other benefit of inheritance, that often goes unmentioned, is the ability to fix bugs in other products. I've had to inherit from some library/framework class to fix a bug in that technology -- it might be a rare situation but it's absolutely invaluable to have that option.
    - zaphar 6y ago
      I'll have to take your word for it that such things exist but experience so far has taught me that: 1. When I have something that is something else with minor modifications that my and everyone else's lives will almost always be better when if I solve the reuse issues with some composition and the is-a problem with an interface. 2. That when I inherit from a class I don't control to fix a bug in that class the fix is both very fragile and usually very short lived. Either way I created a problem for myself later on down the line. I don't disagree that sometimes the framework or library you are using give you no other choice than inheritance. In those cases using inheritance is your only and therefore best option. However I don't consider the framework to be better for it. I consider the framework to worse off for it.
      - wvenable 6y ago
        > if I solve the reuse issues with some composition and the is-a problem with an interface. I'm not sure how that's better -- you're just implementing inheritance with more steps. > is both very fragile and usually very short lived. It is and I know you'd make that point but it's better to be fragile and short lived than completely impossible. I have a least one of these hacks that was completely necessary that has been in place for years.
cogman10 6y ago
I've seen a few clean examples where it works really well. Particularly, Java's AbstractMap is a thing of beauty in the amount of code it saves you if you need to make your own map data structure for whatever reason. One method override and you have all the Map functionality. Otherwise, I agree that it is an Anti-pattern like 99% of the time. Young devs tend to reach for inheritance almost out of instinct whenever they have code they want to share. It's a hard habit to beat out of college grads (Honestly, some of our senior devs haven't learned that lesson :( )

by zaphar 6y ago

donor20 6y ago

I'm no expert, but the mental model of an interface is so simple. The inheritance model I liked in school, but practically the payoff just never seems to show up.

wvenable 6y ago

Lots of things in software development have an is-a relationship. The only time inheritance is an antipattern is when it's used for code-reuse and it isn't modeling an is-a relationship. Once you get to application code there aren't a lot of is-a relationships but inside operating systems, libraries, and frameworks it does come up legitimately.

zaphar 6y ago
Is-a relationships are best handled by interfaces. If you don't have those and only have inheritance then that is the exception I mentioned above. In those cases I would argue that the base class should be composed entirely of abstract methods and the depth of the inheritance hierarchy should be no greater than 1.
- wvenable 6y ago
  If you have something that is something else in almost every way except for one or twos details inheritance is far superior than interfaces. The other benefit of inheritance, that often goes unmentioned, is the ability to fix bugs in other products. I've had to inherit from some library/framework class to fix a bug in that technology -- it might be a rare situation but it's absolutely invaluable to have that option.
  - zaphar 6y ago
    I'll have to take your word for it that such things exist but experience so far has taught me that: 1. When I have something that is something else with minor modifications that my and everyone else's lives will almost always be better when if I solve the reuse issues with some composition and the is-a problem with an interface. 2. That when I inherit from a class I don't control to fix a bug in that class the fix is both very fragile and usually very short lived. Either way I created a problem for myself later on down the line. I don't disagree that sometimes the framework or library you are using give you no other choice than inheritance. In those cases using inheritance is your only and therefore best option. However I don't consider the framework to be better for it. I consider the framework to worse off for it.
    - wvenable 6y ago
      > if I solve the reuse issues with some composition and the is-a problem with an interface. I'm not sure how that's better -- you're just implementing inheritance with more steps. > is both very fragile and usually very short lived. It is and I know you'd make that point but it's better to be fragile and short lived than completely impossible. I have a least one of these hacks that was completely necessary that has been in place for years.

cogman10 6y ago

I've seen a few clean examples where it works really well. Particularly, Java's AbstractMap is a thing of beauty in the amount of code it saves you if you need to make your own map data structure for whatever reason. One method override and you have all the Map functionality. Otherwise, I agree that it is an Anti-pattern like 99% of the time. Young devs tend to reach for inheritance almost out of instinct whenever they have code they want to share. It's a hard habit to beat out of college grads (Honestly, some of our senior devs haven't learned that lesson :( )