• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Rob Spoor
  • Devaka Cooray
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • Tim Holloway
Bartenders:
  • Jj Roberts
  • Al Hobbs
  • Piet Souris

Inheritance versus Composition

 
Greenhorn
Posts: 26
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Composition is decidely a better option than Inheritance.Are there cases where Inheritance has more advantages than Composition?

Thanks
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I wouldn't say that composition is "decidedly better".

Composition provides more flexibility, at the cost of increased complexity. Whether the flexibility is worth the cost depends on the specific case.
 
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Usually inheritance works well if it actually matches the real world relationship you are modeling. Inheritance is prominent in many patterns, such as the Template method pattern.

There is nothing (much) inherently wrong with inheritance, but like anything else it can be misused. The most common objection raised regarding inheritance is that it introduces some coupling between the base class and any derived classes and that this can lead to "brittle" class hierarchies. This is true, but even with Composition there is coupling, either to a concrete class or through the interface.

It is ok to *prefer* composition to inheritance, but not to blindly choose one over the other.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Another Antipattern is using inheritance where it violates Liskov's Substitution Principle.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Usually inheritance works well if it actually matches the real world relationship you are modeling.



This is not necessarily wrong, but it can lead you places that are wrong. We have to remember we're making software, not modeling the real world for modeling's sake. A couple trivial "real world" examples in geometry: a circle "is an" elipse and a square "is a" rectangle, but modeling circle or square through inheritance gets you into big trouble, most likely with Liskov.

Another gotcha to watch for is the need for an object to change class on the fly. I modeled a CD store for a class once and the instructor insisted that a CD in a shopping cart was a different class than a CD in stock. Somehow clicking "add to cart" had to morph an InStockCD to an InCartCD or destroy one and create the other. I took the hit on points and didn't model it that way.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Stan James:
A couple trivial "real world" examples in geometry: a circle "is an" elipse and a square "is a" rectangle, but modeling circle or square through inheritance gets you into big trouble, most likely with Liskov.



It *can* get you into big trouble, but it doesn't *have* to. Most of the problems in that case can also be avoided by making the objects immutable, for example.

An "is a" relationship from the "real world" really can only be a *very* rough heuristic for a software model.
 
Don Morgan
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Sure Stan, the real world relationships are more of a starting point than the complete model.

The CD example you gave illustrates how in some cases the "real world" should be respected. In the real world, a CD does not change just because it is put in a shopping cart (if it did that would make shopping really confusing!), and this does point toward the solution you chose. Unless they were trying to illustrate an antipattern, I don't know how the instructor could recommend having separate classes.
 
author
Posts: 288
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
My view is this

Which one to use? The guide is that inheritance should be only used when subclass �is a� superclass.

--Don�t use inheritance just to get code reuse. If there is no �is a� relationship then use composition for code reuse. Overuse of implementation inheritance (uses the �extends� key word) can break all the subclasses, if the superclass is modified.

--Do not use inheritance just to get polymorphism. If there is no �is a� relationship and all you want is polymorphism then use interface inheritance with composition, which gives you code reuse.
[ March 02, 2006: Message edited by: ak pillai ]
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by ak pillai:
The guide is that inheritance should be only used when subclass �is a� superclass.



The problem with the "is a" heuristic is that it isn't well defined. As mentioned by Stan, mathematically a circle "is an" ellipse, but modelling it that way in software *can* under some circumstances cause serious trouble.

Liskov's Substituation Principle really is the better guide - basically saying that every client should be able to work using the subclass without even knowing about it.

With the circle/ellipse example, it's quite common to find that clients that would work on an ellipse break when having to handle a circle.
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Unless they were trying to illustrate an antipattern, I don't know how the instructor could recommend having separate classes.



He was a database guy through and through. It was a different table in the data model so it ought to be a different class, right? He presents and is on the board at numerous modeling conferences world-wide. I hope they're all data.

Many great points here! I'd forgotten a horrible example of inheritance just because several classes needed to use common database code until this brought back the nightmares. Thanks. The author of that thing now has a title like Chief Technology Architect for a major division of a big company. I'm good with that as long as it keeps him out of the code.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic