Why composition is often better than inheritance • Hacker News Board

Re: Why composition is often better than inheritance

#11

Post by chton » Sun, Jul 06, 2014, 1:00 PM UTC

dtech wrote: post #5

chton wrote: post #2

While it's a well-written article, it really seems like beating a dead horse. Composition over inheritance is a basic rule of OO programming, so much so that it has its own wikipedia page ( http://en.wikipedia.org/wiki/Composition_over_inheritance )

I agree, but it is a well written article with interesting (simplified) real-life examples, so might be good to show the concept to an unaware or beginner programmer. And everyone likes to read stuff that reinforces their own belief :)

That's true, but there are a huge amount of resources about this particular thing already. It's pissing in the ocean by this point.

Re: Why composition is often better than inheritance

#12

Post by chton » Sun, Jul 06, 2014, 1:05 PM UTC

achr2 wrote: post #10

chton wrote: post #2

While it's a well-written article, it really seems like beating a dead horse. Composition over inheritance is a basic rule of OO programming, so much so that it has its own wikipedia page ( http://en.wikipedia.org/wiki/Composition_over_inheritance )

Your wikipedia link actually does a good job of showing why the composition shown in the article is poorly conceived. The whole point of 'composition over inheritance' is that your object is still polymorphic on the composed-of classes.

that's a good point, in the process of trying to use composition the author has made a (very) leaky abstraction.

Re: Why composition is often better than inheritance

#13

Post by Torn » Sun, Jul 06, 2014, 1:06 PM UTC

dtech wrote: post #6

Torn wrote: post #3

Earlier quoted context omitted.

This horse still needs to be beaten. Messy inheritance still plagues product Java, C#, and, with the increasing proliferation of MVC frameworks, JS these days. Hierarchies usually start out small. But, when new features are added and scope creeps, they get deeper and more abstract and messier. Substitutability (i.e. the L in SOLID principles) does require more boiler-plate when using composition though. Interfaces an…

Do you have examples? Most modern Java libraries I know (e.g. Guava) implement interfaces and heavily use composition. The "inheritance based" things mostly got deprecated/replaced when Java 1.5 introduced generics and most libraries needed to be heavily changed anyways.

I've seen a lot of it in product codebases (both Enterprise and Startup) I've had to work with.

I guess it's different when you're maintaining a library - you have more freedom to version up and rewrite things.

Re: Why composition is often better than inheritance

#14

Post by tonyedgecombe » Sun, Jul 06, 2014, 1:09 PM UTC

Torn wrote: post #3

chton wrote: post #2

While it's a well-written article, it really seems like beating a dead horse. Composition over inheritance is a basic rule of OO programming, so much so that it has its own wikipedia page ( http://en.wikipedia.org/wiki/Composition_over_inheritance )

This horse still needs to be beaten. Messy inheritance still plagues product Java, C#, and, with the increasing proliferation of MVC frameworks, JS these days. Hierarchies usually start out small. But, when new features are added and scope creeps, they get deeper and more abstract and messier. Substitutability (i.e. the L in SOLID principles) does require more boiler-plate when using composition though. Interfaces an…

I wish we could move beyond this idea that just because someone uses a particular language their code is going to be poorly written.

Re: Why composition is often better than inheritance

#15

Post by chton » Sun, Jul 06, 2014, 1:10 PM UTC

andybak wrote: post #7

The Wikipedia article chton mentions ( https://en.wikipedia.org/wiki/Composition_over_inheritance ) ends with the following when discussing the drawback of composition (boilerplate for forwarding methods): "This drawback can be avoided by using traits or mixins." Now this is where things get a little blurry for me. Mixins can help with the main drawback of Composition - but Mixins ARE inheritance - so isn't this a co…

the idea is that you create a mixin that has only the reference to the physics object and the forwarding methods. If you implement that mixin, it will be exactly equivalent as writing them out in your class, but you are spared from having to do it for every single class with a physics object.

Remember that a mixin, by definition, isn't the same as inheritance. The methods, fields and properties are compiled into the class, not inherited. It's essentially a fancy way to 'include' a code file.

Re: Why composition is often better than inheritance

#16

Post by [deleted] » Sun, Jul 06, 2014, 1:12 PM UTC

tonyedgecombe wrote: post #14

Torn wrote: post #3

Earlier quoted context omitted.

This horse still needs to be beaten. Messy inheritance still plagues product Java, C#, and, with the increasing proliferation of MVC frameworks, JS these days. Hierarchies usually start out small. But, when new features are added and scope creeps, they get deeper and more abstract and messier. Substitutability (i.e. the L in SOLID principles) does require more boiler-plate when using composition though. Interfaces an…

I wish we could move beyond this idea that just because someone uses a particular language their code is going to be poorly written.

[deleted]

Re: Why composition is often better than inheritance

#17

Post by Zigurd » Sun, Jul 06, 2014, 1:16 PM UTC

dtech wrote: post #6

Torn wrote: post #3

Earlier quoted context omitted.

This horse still needs to be beaten. Messy inheritance still plagues product Java, C#, and, with the increasing proliferation of MVC frameworks, JS these days. Hierarchies usually start out small. But, when new features are added and scope creeps, they get deeper and more abstract and messier. Substitutability (i.e. the L in SOLID principles) does require more boiler-plate when using composition though. Interfaces an…

Do you have examples? Most modern Java libraries I know (e.g. Guava) implement interfaces and heavily use composition. The "inheritance based" things mostly got deprecated/replaced when Java 1.5 introduced generics and most libraries needed to be heavily changed anyways.

The Android View subclasses are an interesting example of a deep inheritance hierarchy in a relatively modern design.

Re: Why composition is often better than inheritance

#18

Post by seanmcdirmid » Sun, Jul 06, 2014, 1:39 PM UTC

chton wrote: post #15

andybak wrote: post #7

The Wikipedia article chton mentions ( https://en.wikipedia.org/wiki/Composition_over_inheritance ) ends with the following when discussing the drawback of composition (boilerplate for forwarding methods): "This drawback can be avoided by using traits or mixins." Now this is where things get a little blurry for me. Mixins can help with the main drawback of Composition - but Mixins ARE inheritance - so isn't this a co…

the idea is that you create a mixin that has only the reference to the physics object and the forwarding methods. If you implement that mixin, it will be exactly equivalent as writing them out in your class, but you are spared from having to do it for every single class with a physics object. Remember that a mixin, by definition, isn't the same as inheritance. The methods, fields and properties are compiled into the…

Mixins can be implemented in a variety of ways, they don't need to be unmodularly inlined into class/object definitions as in scala. Also, mixin-style inheritance is by definition linearized multiple inheritance (at least according to cook/bracha, things get weirder with the Gabriel/Common Lisp definition).

Re: Why composition is often better than inheritance

#19

Post by kissgyorgy » Sun, Jul 06, 2014, 1:43 PM UTC

In Python, we use mixins. Mixins can only inherit from 'object' and nothing else, like this:

    class PhysicsobjectMixin(object):
        def update_physics(self):
            pass
        
        def apply_konckback(self, force):
            pass

        def get_position(self):
            pass


    class FightMixin(object):
        def attack(self):
            pass

        def defend(self):
            pass

    
    class TalkMixin(object):
        def say_something(self):
            pass


    class Character(PhysicsobjectMixin, FightMixin, TalkMixin):
        pass


    class Pickup(PhysicsobjectMixin):
        pass


    class Projectile(PhysicsobjectMixin):
        pass

it's still inheritance, but the classes will be flat; every class only inherits one deep, so there will be no diamond problems and no repeating code.

Re: Why composition is often better than inheritance

#20

Post by jhasse » Sun, Jul 06, 2014, 1:47 PM UTC

kissgyorgy wrote: post #19

In Python, we use mixins. Mixins can only inherit from 'object' and nothing else, like this: class PhysicsobjectMixin(object): def update_physics(self): pass def apply_konckback(self, force): pass def get_position(self): pass class FightMixin(object): def attack(self): pass def defend(self): pass class TalkMixin(object): def say_something(self): pass class Character(PhysicsobjectMixin, FightMixin, TalkMixin): pass cl…

I don't see the difference to interfaces.