Why composition is often better than inheritance
joostdevblog.blogspot.com
Why composition is often better than inheritance
1–10 of 97 posts
Re: Why composition is often better than inheritance
#2While 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)
Re: Why composition is often better than inheritance
#3While 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 and mixins (if available in your language) go some way to helping.
Re: Why composition is often better than inheritance
#4I 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.
Re: Why composition is often better than inheritance
#5While 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 :)
Re: Why composition is often better than inheritance
#6While 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…
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.
Re: Why composition is often better than inheritance
#7The 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 contradiction?
If I use PhysicsObjectMixin in my CharacterComposition class then I have to inherit from it. So aren't we back with the perils of inheritance?
Re: Why composition is often better than inheritance
#8While 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 haven't really noticed that this particular horse needs much beating (I work mainly in the C# world). It's drilled so well into beginner programmers that they tend to forget other principles like Single Responsibility.
Re: Why composition is often better than inheritance
#9I 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 think so too.
In JS it's rather easy to compose objects. In Java it feels clunky, you code looks kinda wrong when you done.
Re: Why composition is often better than inheritance
#10While 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.