Why composition is often better than inheritance • Hacker News Board

Re: Why composition is often better than inheritance

#31

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

seanmcdirmid wrote: post #18

chton wrote: post #15

Earlier quoted context omitted.

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).

It's true that they can be implemented in the same way, but the idea remains the same. Seeing mixins as inheritance is a far narrower definition than held by most languages (or libraries) that implement them. Mixins don't put any requirements on the polymorphism of the object that implements them, which ordinary inheritance does.

It's common to use the Flavors/Lisp defintion of mixins, but I'll make sure to read up on the Bracha-Cook paper about them.

Re: Why composition is often better than inheritance

#32

Post by yayitswei » Sun, Jul 06, 2014, 2:10 PM UTC

By the way, I encourage everyone to try out their game, Awesomenauts. Think Super Smash Brothers meets Dota. It's a lot of fun to play!

Re: Why composition is often better than inheritance

#33

Post by [deleted] » Sun, Jul 06, 2014, 2:17 PM UTC

userbinator wrote: post #30

While it's possible to overuse inheritance, I don't think replacing it with composition is all that much better, and in addition all those forwarding methods that do nothing more than call another (could they even be optimised out?) are a great example of code that would need to be written, consuming resources like programmer time, but otherwise serves no true useful purpose to the functionality of the software. The…

[deleted]

Re: Why composition is often better than inheritance

#34

Post by seanmcdirmid » Sun, Jul 06, 2014, 2:23 PM UTC

chton wrote: post #31

seanmcdirmid wrote: post #18

Earlier quoted context omitted.

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).

It's true that they can be implemented in the same way, but the idea remains the same. Seeing mixins as inheritance is a far narrower definition than held by most languages (or libraries) that implement them. Mixins don't put any requirements on the polymorphism of the object that implements them, which ordinary inheritance does. It's common to use the Flavors/Lisp defintion of mixins, but I'll make sure to read up o…

There have been many implementations of mixins, and many that I'm aware of, like Scala, are inheritance based. The nice thing about mixin style inheritance is that inheritance becomes much more composable. The type of an object then is not its class, but the set of mixins it extends.

Re: Why composition is often better than inheritance

#35

Post by _pmf_ » Sun, Jul 06, 2014, 2:32 PM UTC

The burden of proof should fall onto the user of inheritance to justify his decision. Interfaces plug delegates is more tedious to implement, but greatly reduces the chances of an architecture turning into a complete train wreck.

I often wonder why declarative delagating is not a first class concern in programming languages.

Re: Why composition is often better than inheritance

#36

Post by fithisux » Sun, Jul 06, 2014, 2:35 PM UTC

Why often and not always? Can you provide an exceptional case?

Re: Why composition is often better than inheritance

#37

Post by falcolas » Sun, Jul 06, 2014, 2:36 PM UTC

Walkman wrote: post #29

jhasse wrote: post #20

Earlier quoted context omitted.

I don't see the difference to interfaces.

With interfaces, the above example would look like this: from abc import ABCMeta class PhysicsobjectMixin(ABCMeta): @abstractmethod def update_physics(self): pass @abstractmethod def apply_konckback(self, force): pass @abstractmethod def get_position(self): pass class FightMixin(ABCMeta): @abstractmethod def attack(self): pass @abstractmethod def defend(self): pass class TalkMixin(ABCMeta): @abstractmethod def say_so…

It's not DRY, but then again, the chances of not overwriting, or more likely adding something to that method are pretty small when your project becomes more than an illustration of a principle.

For example, what if you want to add custom animations any time your `Character` takes an action? Suddenly, all that boilerplate you "abstracted" away through mix-ins is back, with a vengeance. How about if your physics for a `Projectile` are different than for a `Pickup`? What if your character suddenly picks up a Sling of Thrown Voices, and needs to apply conversation snippets to its projectiles?

In simple examples, mixins are great and reduce a lot of boilerplate, but in reality they are rarely so clean.

Re: Why composition is often better than inheritance

#38

Post by falcolas » Sun, Jul 06, 2014, 2:40 PM UTC

jiaweihli wrote: post #4

I think this is a tooling issue. People initially tend to favor inheritance because it looks cleaner than composition. Mixing a lot of unrelated code in the same class makes things hard to find. (which method applies to which composed object?) In languages that build in a concept of traits/mixins however, this isn't an issue.

I disagree that mixing remove this issue. Even with mixins, you will still have places where all of that boilerplate from composition comes back, just with a concept like Python's `super` thrown back in.

And mixins in the wild are rarely so pure as people like to think they are - they often inherit from their own parents or other mix-ins, creating the diamond (or worse!) inheritance problem outlined in the article.

Re: Why composition is often better than inheritance

#39

Post by falcolas » Sun, Jul 06, 2014, 2:43 PM UTC

Walkman wrote: post #27

heylo wrote: post #24

Earlier quoted context omitted.

Is that just multiple inheritance, or are mixins something else?

Multiple inheritance with your discipline to not do more complicated things. Only inherit from base 'object', nothing else, so you will have no complicated inheritance problems.

Which, in reality, rarely happens. Looking through the code in the Python standard library shows how even the exemplar mixin examples are rarely so pure.

Re: Why composition is often better than inheritance

#40

Post by lispm » Sun, Jul 06, 2014, 2:45 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…

That's just normal multiple-inheritance. Nothing like mixins.

Mixins would be if the classes actually contribute pieces which combine in an interesting way. Like a border-mixin added to a button class would add to the drawing and to the geometry of the object.