3 ms·

I really don't get why people keep repeating "class inheritance hierarchies are bad". If one understands Implementation vs. Interface inheritance and the intent

I really don't get why people keep repeating "class inheritance hierarchies are bad". If one understands Implementation vs. Interface inheritance and the intent behind each (the former strongly couples the code while the latter does not) then one can judiciously use inheritance techniques correctly. I recommend a study of Bertrand Meyer's OOSC2 and language Eiffel - https://en.wikipedia.org/wiki/Object-Oriented_Software_Construction https://en.wikipedia.org/wiki/Object-Oriented_Software_Const...

gyrovorbis 3y ago
It's just the latest hipster language trend. When OO was new, structural C was evil. When functional programming happened, everything before that was evil... Because, yes, sharing state among classes for code reuse, is fundamentally evil... How dare you want to couple state and logic? Almost like every single UI framework in every mainstream language has converged upon OO as the best way to model the problem at hand... GTk even invented a similar type system to what was mentioned in this PDF just to give C OOP constructs... Now witness as the Rust language has failed to produce a compelling UI/widgeting framework or paradigm, and the best ones out there are Qt-based or GTk-bindings (letting C hilariously handle the OOP for Rust).
- rramadass 3y ago
  >It's just the latest hipster language trend. When OO was new, structural C was evil. When functional programming happened, everything before that was evil... Right. By any measure OOD/OOP has been enormously successful in the real world and hence it is annoying to see blanket statements like "OOD/OOP/Inheritance/etc. is bad" on HN (i expected better). It is one thing to discuss cautions/caveats/different approaches but to dismiss the whole thing is quite silly. Hence my attempt at edification of the readers :-)
jupp0r 3y ago
The way I'm thinking about it (just a different expression of the exact same thought) is that inheritance as a means to share code is bad, while inheritance as a means to leverage polymorphism is good. Polymorphic classes can still share code, but this should be done using composition.
- rramadass 3y ago
  > inheritance as a means to share code is bad, Not necessarily; if they are strongly coupled related concepts within the same module then it is perfectly fine (eg. private inheritance in C++). Here you are basically structuring for code reuse and not is-a relationship. >inheritance as a means to leverage polymorphism is good. This is the "standard" idea of inheritance i.e. sub-typing using Liskov Substitution Principle. > Polymorphic classes can still share code, but this should be done using composition. Not necessarily as a combination of the above two should make clear.
Fire-Dragon-DoL 3y ago
The reason is implicit makes really easy to miss things and the majority of software devs have very poor understanding of coupling. Consequence is if inheritance is a thing, you'll see monsters in the code. If inheritance is not available, the problem doesn't exist. Same goes for immutability, in the end our tools are tuning for the lowest performers
- jupp0r 3y ago
  The ability to reason about code as you are reading it is not only important to "lowest performers".
  - Fire-Dragon-DoL 3y ago
    Absolutely agree, I very much prefer it
- rramadass 3y ago
  Not true. The basic idea behind "Inheritance" is simple and can be understood by all programmers. Its realization through various language features and their combinations is what makes it somewhat confusing. Once explained and practiced with discipline, inheritance is very powerful. See my other comment: https://news.ycombinator.com/item?id=36428689 https://news.ycombinator.com/item?id=36428689 See also: https://thevaluable.dev/guide-inheritance-oop/ https://thevaluable.dev/guide-inheritance-oop/
  - jupp0r 3y ago
    Just because something is easy to understand at first does not make it suitable for designing maintainable software. I can understand the concept really well and it sounds completely appealing. When digging through the 18th code base with 12 deep inheritance hierarchies and various overwritten or not overwritten or combination thereof member functions where all you can do to follow control flow is to employ a debugger do you get the notion that this simple idea might not be so great after all.
DarkNova6 3y ago
I think inheritance is the most convenient thing which came out of OOP, but interfaces are the most valuable one. At least for business applications, you want to keep your behaviour and state separate. And people following OOP dogmatically will (ab)use encapsulation for use-cases where your data should be transparent. Contrast this to interfaces, which are essentially composable specifications on code-level (and I absolutely love that Java uses interfaces to describe anonymous classes due to the power it gives you for documentation and specification).
- rramadass 3y ago
  You might find Program Development in Java: Abstraction, Specification, and Object-Oriented Design by Barbara Liskov with John Guttag interesting.
  - DarkNova6 3y ago
    I am always a sucker for good book recommendations. Thank you!
    - rramadass 3y ago
      The book is by the great Barbara Liskov herself (https://en.wikipedia.org/wiki/Barbara_Liskov https://en.wikipedia.org/wiki/Barbara_Liskov) the pioneer of Abstract Data Types, Subtyping, OOD etc. It is basically a rewrite of their classic text Abstraction and Specification in Program Development (1986) with the example language now being Java. It is not a popular cookbook but a fundamental programming concepts book which needs serious study. I highly recommend it.

gyrovorbis 3y ago

It's just the latest hipster language trend. When OO was new, structural C was evil. When functional programming happened, everything before that was evil... Because, yes, sharing state among classes for code reuse, is fundamentally evil... How dare you want to couple state and logic? Almost like every single UI framework in every mainstream language has converged upon OO as the best way to model the problem at hand... GTk even invented a similar type system to what was mentioned in this PDF just to give C OOP constructs... Now witness as the Rust language has failed to produce a compelling UI/widgeting framework or paradigm, and the best ones out there are Qt-based or GTk-bindings (letting C hilariously handle the OOP for Rust).

rramadass 3y ago
>It's just the latest hipster language trend. When OO was new, structural C was evil. When functional programming happened, everything before that was evil... Right. By any measure OOD/OOP has been enormously successful in the real world and hence it is annoying to see blanket statements like "OOD/OOP/Inheritance/etc. is bad" on HN (i expected better). It is one thing to discuss cautions/caveats/different approaches but to dismiss the whole thing is quite silly. Hence my attempt at edification of the readers :-)

jupp0r 3y ago

The way I'm thinking about it (just a different expression of the exact same thought) is that inheritance as a means to share code is bad, while inheritance as a means to leverage polymorphism is good. Polymorphic classes can still share code, but this should be done using composition.

rramadass 3y ago
> inheritance as a means to share code is bad, Not necessarily; if they are strongly coupled related concepts within the same module then it is perfectly fine (eg. private inheritance in C++). Here you are basically structuring for code reuse and not is-a relationship. >inheritance as a means to leverage polymorphism is good. This is the "standard" idea of inheritance i.e. sub-typing using Liskov Substitution Principle. > Polymorphic classes can still share code, but this should be done using composition. Not necessarily as a combination of the above two should make clear.

Fire-Dragon-DoL 3y ago

The reason is implicit makes really easy to miss things and the majority of software devs have very poor understanding of coupling. Consequence is if inheritance is a thing, you'll see monsters in the code. If inheritance is not available, the problem doesn't exist. Same goes for immutability, in the end our tools are tuning for the lowest performers

jupp0r 3y ago
The ability to reason about code as you are reading it is not only important to "lowest performers".
- Fire-Dragon-DoL 3y ago
  Absolutely agree, I very much prefer it
rramadass 3y ago
Not true. The basic idea behind "Inheritance" is simple and can be understood by all programmers. Its realization through various language features and their combinations is what makes it somewhat confusing. Once explained and practiced with discipline, inheritance is very powerful. See my other comment: https://news.ycombinator.com/item?id=36428689 https://news.ycombinator.com/item?id=36428689 See also: https://thevaluable.dev/guide-inheritance-oop/ https://thevaluable.dev/guide-inheritance-oop/
- jupp0r 3y ago
  Just because something is easy to understand at first does not make it suitable for designing maintainable software. I can understand the concept really well and it sounds completely appealing. When digging through the 18th code base with 12 deep inheritance hierarchies and various overwritten or not overwritten or combination thereof member functions where all you can do to follow control flow is to employ a debugger do you get the notion that this simple idea might not be so great after all.

DarkNova6 3y ago

I think inheritance is the most convenient thing which came out of OOP, but interfaces are the most valuable one. At least for business applications, you want to keep your behaviour and state separate. And people following OOP dogmatically will (ab)use encapsulation for use-cases where your data should be transparent. Contrast this to interfaces, which are essentially composable specifications on code-level (and I absolutely love that Java uses interfaces to describe anonymous classes due to the power it gives you for documentation and specification).

rramadass 3y ago
You might find Program Development in Java: Abstraction, Specification, and Object-Oriented Design by Barbara Liskov with John Guttag interesting.
- DarkNova6 3y ago
  I am always a sucker for good book recommendations. Thank you!
  - rramadass 3y ago
    The book is by the great Barbara Liskov herself (https://en.wikipedia.org/wiki/Barbara_Liskov https://en.wikipedia.org/wiki/Barbara_Liskov) the pioneer of Abstract Data Types, Subtyping, OOD etc. It is basically a rewrite of their classic text Abstraction and Specification in Program Development (1986) with the example language now being Java. It is not a popular cookbook but a fundamental programming concepts book which needs serious study. I highly recommend it.