4 ms·

I hate inheritance.

nforgerit 3y ago
Some months ago, I stumbled into an OOP inheritance rabbithole which got me thinking the same: - Isn't the (biological) concept of inheritance built at it's core around the idea of "generations"? How does that make any sense in OOP? - Why do Java beginner courses still teach Inheritance like it was 1995 with all the bells and whistles and dogs and cats and mammals? - Why do they teach Inheritance and later introduce "favor composition to inheritance"? Doesn't this just confuse everyone? - Why does Inheritance have first-class syntax support in an OOP language like Java ("extends") whereas Composition usually needs to be "engineered" using some more complex patterns, e.g. DI? Most of it is probably for historical reasons, i guess.
- psychoslave 3y ago
  I don't know for Java currently but for example in Ruby composition is simply a matter of putting your code in a module rather than a class. Then you can extend any class with this module. You can even extend instances. That is 3.extends(Some_module).method_from_some_module is perfectly valid. In PHP, surely you can use traits.
  - emodendroket 3y ago
    Of the many models of “composition” that are possible I think Ruby’s free-for-all blend of mix-ins and monkey patches is the only one that can drive a maintenance programmer more insane than a deep hierarchy of inheritance of Java classes.
    - shagie 3y ago
      irb(main):001:0> "bar".foo Traceback (most recent call last): 4: from /usr/bin/irb:23:in `<main>' 3: from /usr/bin/irb:23:in `load' 2: from /Library/Ruby/Gems/2.6.0/gems/irb-1.0.0/exe/irb:11:in `<top (required)>' 1: from (irb):1 NoMethodError (undefined method `foo' for "bar":String) Did you mean? for irb(main):002:0> class String irb(main):003:1> def foo irb(main):004:2> "foobar!" irb(main):005:2> end irb(main):006:1> end => :foo irb(main):007:0> "bar".foo => "foobar!" irb(main):008:0> Yes! Let's modify the core library String class on the fly to add new functions to it. There are things about ruby that truly scare me if my goal was to write secure and reasonable code.
      - emodendroket 3y ago
        Right, that’s monkey patching. You run into the real problems when you have multiple people wanting to add them. Ruby isn’t alone in supporting this functionality (you can fiddle with JavaScript prototypes, for instance), but I think it is unique how much it is encouraged (at least in Rails world). I think extension methods are a much better model to achieve something similar.
        shagie 3y ago
        There are also some really weird/powerful/voodoo things that you can do when that is combined with the first class environments. The "why Scheme didn't do this": First-class environments - http://funcall.blogspot.com/2009/09/first-class-environments.html http://funcall.blogspot.com/2009/09/first-class-environments... why Ruby did (and wasn't a good idea): Ruby Conf 2011 Keeping Ruby Reasonable https://youtu.be/vbX5BVCKiNs https://youtu.be/vbX5BVCKiNs Consider where you can slip in a block invocation and the following code: def mal(&block) block.call block.binding.eval('a = 43') end a = 42 puts a mal do puts 1 end puts a and that that means that you've got full access to be able to inspect and manipulate all of the variables in scope at the time of the invocation. While that example is rather obvious, it can be done much more subtly too. The power of ruby to do meta programming and by extension some really neat DSLs also provides it with some dangerous tools that are otherwise rather difficult to track down.
      - projektfu 3y ago
        This is the Smalltalkiness of Ruby. Why have a separate place to put a function that operates only on strings when you can put it in String? Of course, in Smalltalk you might have #trim defined by two different packages and they might conflict. Then what? Maybe you have to manage that complexity. However, it's not much different from having conflicting functions in the global namespace in C, but actually easier to resolve in a given situation.
        emodendroket 3y ago
        Well, I suppose that's compelling if you're one of the many programmers trying to decide if you will implement your project in Ruby or C.
- celaleddin 3y ago
  I really liked all these questions, thanks for sharing. I'll think about them.
- emodendroket 3y ago
  If every class inherits Object then you probably need to understand the concept still, even if it’s no longer favored for organizing your own business logic. Besides, you will encounter other people’s code that doesn’t follow all the best practices eventually. And I’m not sure anyone has come up with a better way of teaching inheritance in the past few decades.
- pie_flavor 3y ago
  Because it's an object-oriented language, and so its primary paradigm is object-orientation. Various style guides will tell you that object-orientation is bad and you should try writing in a procedural style instead, but the correct answer when you pine for procedural programming is to stop using Java.
- tored 3y ago
  I remember when C++ was touted as a superior language to Java because C++ has support for multiple inheritance.
  - UncleMeat 3y ago
    Java has interfaces with method implementations now. You can do multiple inheritance with it too :P
    - throwawaymobule 3y ago
      they did avoid the diverging diamond of death by making it a compiler error to have duplicate functions though. AFAIK,that's the only big downside to multiple inheritance.
- whstl 3y ago
  "Why does Inheritance have first-class syntax support in an OOP language like Java ("extends") whereas Composition usually needs to be "engineered" using some more complex patterns, e.g. DI?" I think the main reason is that DI is seen as an orthogonal concept by language designers, so you'd need new two first-class features in a language. If you do composition without injection (e.g.: by having new ChildObject() in the constructor), you don't really require that many more lines of code compared to inheritance. class Car { private Engine engine; public Car() { engine = new Engine(); } public void drive() { engine.start(); System.out.println("Driving..."); engine.stop(); } } Of course it's much less flexible and less testable than composition + injection, but not that inflexible when compared to inheritance. And first-class support for only that would make the feature a bit useless without DI...
- paulddraper 3y ago
  > How does that make any sense in OOP? OOP inheritance forms a tree, and that is the language of trees (parent, child, ancestor, descendant, sibling). > Why do Java beginner courses still teach Inheritance like it was 1995 > Why do they teach Inheritance and later introduce "favor composition to inheritance"? Doesn't this just confuse everyone? Codecademy's course introduces inheritance in module 9 of 11, and calls it "deeper object-oriented" feature: https://www.codecademy.com/learn/learn-java https://www.codecademy.com/learn/learn-java > Why does Inheritance have first-class syntax support in an OOP language like Java ("extends") whereas Composition usually needs to be "engineered" using some more complex patterns, e.g. DI? Class members absolutely have first class syntax. DI is composition with IoC container.
  - deleted 3y ago
    [deleted]
- lmm 3y ago
  Yep. You've got to remember that Java is nearly 30 years old; at the time making a distinction between interfaces and abstract classes was seen as a radical move. Newer languages have better support for more decoupled ways of doing things, e.g. Rust's use of typeclasses (which it calls traits for some reason) or Kotlin's built-in support for delegation.
  - Twisol 3y ago
    > Rust's use of typeclasses (which it calls traits for some reason) Scala and (apparently) PHP call them traits too, among many others [1] -- Rust wasn't the first here. [1] https://en.wikipedia.org/wiki/Trait_(computer_programming) https://en.wikipedia.org/wiki/Trait_(computer_programming)
    - lmm 3y ago
      The thing that Rust calls traits is quite different from the thing that Scala and PHP call traits, and much more like the thing that many languages call typeclasses.
- anonymoushn 3y ago
  Why do we need DI to declare that a class has a member?

I hate inheritance.

Some months ago, I stumbled into an OOP inheritance rabbithole which got me thinking the same: - Isn't the (biological) concept of inheritance built at it's core around the idea of "generations"? How does that make any sense in OOP? - Why do Java beginner courses still teach Inheritance like it was 1995 with all the bells and whistles and dogs and cats and mammals? - Why do they teach Inheritance and later introduce "favor composition to inheritance"? Doesn't this just confuse everyone? - Why does Inheritance have first-class syntax support in an OOP language like Java ("extends") whereas Composition usually needs to be "engineered" using some more complex patterns, e.g. DI? Most of it is probably for historical reasons, i guess.

psychoslave 3y ago
I don't know for Java currently but for example in Ruby composition is simply a matter of putting your code in a module rather than a class. Then you can extend any class with this module. You can even extend instances. That is 3.extends(Some_module).method_from_some_module is perfectly valid. In PHP, surely you can use traits.
- emodendroket 3y ago
  Of the many models of “composition” that are possible I think Ruby’s free-for-all blend of mix-ins and monkey patches is the only one that can drive a maintenance programmer more insane than a deep hierarchy of inheritance of Java classes.
  - shagie 3y ago
    irb(main):001:0> "bar".foo Traceback (most recent call last): 4: from /usr/bin/irb:23:in `<main>' 3: from /usr/bin/irb:23:in `load' 2: from /Library/Ruby/Gems/2.6.0/gems/irb-1.0.0/exe/irb:11:in `<top (required)>' 1: from (irb):1 NoMethodError (undefined method `foo' for "bar":String) Did you mean? for irb(main):002:0> class String irb(main):003:1> def foo irb(main):004:2> "foobar!" irb(main):005:2> end irb(main):006:1> end => :foo irb(main):007:0> "bar".foo => "foobar!" irb(main):008:0> Yes! Let's modify the core library String class on the fly to add new functions to it. There are things about ruby that truly scare me if my goal was to write secure and reasonable code.
    - emodendroket 3y ago
      Right, that’s monkey patching. You run into the real problems when you have multiple people wanting to add them. Ruby isn’t alone in supporting this functionality (you can fiddle with JavaScript prototypes, for instance), but I think it is unique how much it is encouraged (at least in Rails world). I think extension methods are a much better model to achieve something similar.
      - shagie 3y ago
        There are also some really weird/powerful/voodoo things that you can do when that is combined with the first class environments. The "why Scheme didn't do this": First-class environments - http://funcall.blogspot.com/2009/09/first-class-environments.html http://funcall.blogspot.com/2009/09/first-class-environments... why Ruby did (and wasn't a good idea): Ruby Conf 2011 Keeping Ruby Reasonable https://youtu.be/vbX5BVCKiNs https://youtu.be/vbX5BVCKiNs Consider where you can slip in a block invocation and the following code: def mal(&block) block.call block.binding.eval('a = 43') end a = 42 puts a mal do puts 1 end puts a and that that means that you've got full access to be able to inspect and manipulate all of the variables in scope at the time of the invocation. While that example is rather obvious, it can be done much more subtly too. The power of ruby to do meta programming and by extension some really neat DSLs also provides it with some dangerous tools that are otherwise rather difficult to track down.
    - projektfu 3y ago
      This is the Smalltalkiness of Ruby. Why have a separate place to put a function that operates only on strings when you can put it in String? Of course, in Smalltalk you might have #trim defined by two different packages and they might conflict. Then what? Maybe you have to manage that complexity. However, it's not much different from having conflicting functions in the global namespace in C, but actually easier to resolve in a given situation.
      - emodendroket 3y ago
        Well, I suppose that's compelling if you're one of the many programmers trying to decide if you will implement your project in Ruby or C.
celaleddin 3y ago
I really liked all these questions, thanks for sharing. I'll think about them.
emodendroket 3y ago
If every class inherits Object then you probably need to understand the concept still, even if it’s no longer favored for organizing your own business logic. Besides, you will encounter other people’s code that doesn’t follow all the best practices eventually. And I’m not sure anyone has come up with a better way of teaching inheritance in the past few decades.
pie_flavor 3y ago
Because it's an object-oriented language, and so its primary paradigm is object-orientation. Various style guides will tell you that object-orientation is bad and you should try writing in a procedural style instead, but the correct answer when you pine for procedural programming is to stop using Java.
tored 3y ago
I remember when C++ was touted as a superior language to Java because C++ has support for multiple inheritance.
- UncleMeat 3y ago
  Java has interfaces with method implementations now. You can do multiple inheritance with it too :P
  - throwawaymobule 3y ago
    they did avoid the diverging diamond of death by making it a compiler error to have duplicate functions though. AFAIK,that's the only big downside to multiple inheritance.
whstl 3y ago
"Why does Inheritance have first-class syntax support in an OOP language like Java ("extends") whereas Composition usually needs to be "engineered" using some more complex patterns, e.g. DI?" I think the main reason is that DI is seen as an orthogonal concept by language designers, so you'd need new two first-class features in a language. If you do composition without injection (e.g.: by having new ChildObject() in the constructor), you don't really require that many more lines of code compared to inheritance. class Car { private Engine engine; public Car() { engine = new Engine(); } public void drive() { engine.start(); System.out.println("Driving..."); engine.stop(); } } Of course it's much less flexible and less testable than composition + injection, but not that inflexible when compared to inheritance. And first-class support for only that would make the feature a bit useless without DI...
paulddraper 3y ago
> How does that make any sense in OOP? OOP inheritance forms a tree, and that is the language of trees (parent, child, ancestor, descendant, sibling). > Why do Java beginner courses still teach Inheritance like it was 1995 > Why do they teach Inheritance and later introduce "favor composition to inheritance"? Doesn't this just confuse everyone? Codecademy's course introduces inheritance in module 9 of 11, and calls it "deeper object-oriented" feature: https://www.codecademy.com/learn/learn-java https://www.codecademy.com/learn/learn-java > Why does Inheritance have first-class syntax support in an OOP language like Java ("extends") whereas Composition usually needs to be "engineered" using some more complex patterns, e.g. DI? Class members absolutely have first class syntax. DI is composition with IoC container.
- deleted 3y ago
  [deleted]
lmm 3y ago
Yep. You've got to remember that Java is nearly 30 years old; at the time making a distinction between interfaces and abstract classes was seen as a radical move. Newer languages have better support for more decoupled ways of doing things, e.g. Rust's use of typeclasses (which it calls traits for some reason) or Kotlin's built-in support for delegation.
- Twisol 3y ago
  > Rust's use of typeclasses (which it calls traits for some reason) Scala and (apparently) PHP call them traits too, among many others [1] -- Rust wasn't the first here. [1] https://en.wikipedia.org/wiki/Trait_(computer_programming) https://en.wikipedia.org/wiki/Trait_(computer_programming)
  - lmm 3y ago
    The thing that Rust calls traits is quite different from the thing that Scala and PHP call traits, and much more like the thing that many languages call typeclasses.
anonymoushn 3y ago
Why do we need DI to declare that a class has a member?