Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why composition is often better than inheritance

joostdevblog.blogspot.com

Post reply on HN
Print view View original

61–70 of 97 posts

Re: Why composition is often better than inheritance

#61

Post by judk »

jerf wrote: post #41
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 )

Many of us still learned about OO in school, where inheritance was all but beaten into us, and composition was not mentioned. And based on what I've seen in interviews, this is still a common model taught in school. Composition is in the process of winning as the default method of composing things together in OO (see, for instance, Go), but it has not won yet. And on the topic of Go, note how most common OO languages…

Composition always takes more boilerplate, because inheritance is noting more than composition with a bunch of default choices for a privileged component (single inheritance) or arbitrary sorting of components (multiple inheritance) made so the programmer doesn't have to write them (but also loses control).

Re: Why composition is often better than inheritance

#62

Post by al2o3cr »

Meh. I think this phrase has been repeated until it has lost any connection with the original intent and turned into a generic "INHERITANCE BAD! COMPOSITION GOOD!" without much meaning attached to either word.

I haven't found the original source, but I've always presumed the statement originally referred to some of the bizarro "inheritance-as-composition" stuff in the early C++ days: for instance, you might have a class 'Window' and a class 'Button', then combine them with multiple inheritance to get a 'WindowWithButton', then inherit from that and a 'Scrollbar' class to get 'WindowWithButtonAndScrollbar'.

I can't imagine anybody thinking of that as a "good" pattern today, but remember it was the '90s. :)

Nowadays, the basic statement has been dogmatized to the point where you get code like this:

https://github.com/elm-city-craftworks/broken_record/blob/ma...

This code re-implements Ruby's built-in method lookup algorithm, but with per-instance objects and none of the optimizations available to the real thing. It basically remakes inheritance, slowly and poorly, using composition.

The other one that makes me scratch my head: people who rail against inheritance, then suggest mixins as an alternative. At least in Ruby, the two are equivalent. Check the `ancestors` property on a class with mixins sometime if you don't believe me.

TL;DR (too late) - use your damn brain to make decisions, not just parrot slogans.

Re: Why composition is often better than inheritance

#63

Post by shanemhansen »

judk wrote: post #61
jerf wrote: post #41

Earlier quoted context omitted.

Many of us still learned about OO in school, where inheritance was all but beaten into us, and composition was not mentioned. And based on what I've seen in interviews, this is still a common model taught in school. Composition is in the process of winning as the default method of composing things together in OO (see, for instance, Go), but it has not won yet. And on the topic of Go, note how most common OO languages…

Composition always takes more boilerplate, because inheritance is noting more than composition with a bunch of default choices for a privileged component (single inheritance) or arbitrary sorting of components (multiple inheritance) made so the programmer doesn't have to write them (but also loses control).

Go chose to have composition as a first class citizen rather than OO. It's called struct embedding. Embedding requires minimal boilerplate.

Re: Why composition is often better than inheritance

#64

Post by cryptophile »

In simplified terms, an object is just a hashtable pointing to a parent hashtable. Now the question becomes: Is it better to embed another hashtable inside the hashtable ('has') or better to store its fields in the parent hashtable ('is')?

My question is: Why would this question even be relevant?

Re: Why composition is often better than inheritance

#65

Post by mamcx »

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.

But is true that some languages make some kind of bad/problematic code MORE common, and requiere discipline and/or knowledge to combat it (and like in this case, is likely that the avg developer is not aware of the alternatives at all.)

Re: Why composition is often better than inheritance

#66

Post by mercurial »

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.

But a language is not just syntax and a compiler, it is an ecosystem. And for good or bad, programmers rely on and are influenced by this ecosystem.

Re: Why composition is often better than inheritance

#67

Post by mercurial »

Torn wrote: post #13
dtech wrote: post #6

Earlier quoted context omitted.

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.

Sadly, many of the "older" programmers haven't learned any better. And sometimes it's a limitation of the language (eg, Java which doesn't allow default implementations in interfaces).

Re: Why composition is often better than inheritance

#68

Post by joevandyk »

al2o3cr wrote: post #62

Meh. I think this phrase has been repeated until it has lost any connection with the original intent and turned into a generic "INHERITANCE BAD! COMPOSITION GOOD!" without much meaning attached to either word. I haven't found the original source, but I've always presumed the statement originally referred to some of the bizarro "inheritance-as-composition" stuff in the early C++ days: for instance, you might have a cl…

You can only inherit from one class in ruby. You can mixin multiple modules into a class. So they aren't entirely equivalent.

Re: Why composition is often better than inheritance

#69

Post by timr »

benihana wrote: post #46
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 )

> While it's a well-written article, it really seems like beating a dead horse I graduated college about 10 years ago, and I was never taught anything near composition over inheritance. I was told about inheritance, but had to learn from other coworkers and experience that composition is much favored over inheritance. Now I mentor a number of junior developers and they need to be told composition over inheritance oft…

"I was told about inheritance, but had to learn from other coworkers and experience that composition is much favored over inheritance."

You weren't taught that, because it isn't true. Inheritance is appropriate sometimes, composition at other times.

In particular, when a two objects are modeled by an ISA relationship, you should use inheritance. When they're modeled by HASA, you should use composition.

A Dog is not an Animal that includes Barkable and PeeOnHydrantable, and a SpaceShuttle is not a descendant of Airplane.

Post reply on HN