This week's book giveaway is in the Jython/Python forum.
We're giving away four copies of Murach's Python Programming and have Michael Urban and Joel Murach on-line!
See this thread for details.
Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Inheritance and aggregation  RSS feed

Roberto Diaz
Ranch Hand
Posts: 40
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Need some help in understanding inheritance
and aggregation. I have read lots of technical
jargon and it is all getting convoluted.
Some simple explanations will be of great help
to me.
Zafar Ali
Ranch Hand
Posts: 64
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi Roberto Diaz , I am trying to explain .
If you know something about a category of things, you automatically know some things you can transfer to other categories.
If you know something is an animal, u take for granted that it eats, sleeps,has a way of being born, has a way of getting from one place to another... But imagine that animals , amphibians and reptiles are all animals. also cous dogs, cats are groped in category mamals. Object Orientation refers to this an "Inheritance".In Uml inheritance represented with a line that connects the parent to a child class, and on the parent's side you put an open triangel.(sorry i can't show here).
Aggregation=> Sometimes a class consists of a number of component classes. This is a special type of relationship called aggregation.
Kathy Sierra
Cowgirl and Author
Posts: 1589
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Howdy -- I'll take a shot at it
Inheritance means an "IS-A" relationship, while aggregation means "HAS-A".
To know if you've got your inheritance structure working, always ask if it makes to say,

"A subclass IS-A superclass" (but substitute the appropriate class names, of course)
For example, if Dog extends Animal, ask,
"A Dog IS-A Animal". If that does not make sense, you probably don't have a valid inheritance structure.
Here's an example that goes in the wrong direction:
Car extends Mini
Does it make sense to say,
"A Car IS-A Mini" (well, to Jessica it does... shouldn't ALL cars be Minis?
But since in the real world, NOT every Car IS-A Mini, that inheritance structure is upside down.
That example demonstrates inheritance in the wrong direction.
But what about inheritance that SHOULD have been aggregation? For example, imagine that you have an oven class that has lots of oven-related cooking code.
Now you come along and you decide to make a Kitchen class. You don't want to rewrite all that Oven code in your Kitchen class, so you EXTEND Oven and let Kitchen inherit all that Oven functionality.
Does it make sense to say, "Kitchen IS-A Oven"

But does it make sense to say, "Kitchen HAS-A Oven"
So use aggregation and let the Kitchen HAVE a Oven instance variable and everybody is happy

In general, if type X IS-A type Y, then it usually means that type X extends Y, or that type X implements Y.
But if type X HAS-A type Y, then it probably means type X has an instance variable of type Y.
Keep in mind that most (not all) good OO designs have an inheritance structure that is a kilometer wide and a centimeter deep, with aggregation a more appropriate option for most classes.
Just look in the Java API and you'll find that most clasess are only one to two levels deep. (Except AWT and Swing, of course...)
Also, consider that interfaces often make more sense than superclasses, since using IS-A with interfaces lets you be more than just a single type of thing. I can be a Human, I can be "One who can be flattened" (implements Serializable), "One who can be Remote" (RMI-able), and "One who rides horses" (implements Cowgirl), and "One who eats ice cream" (implements BenAndJerrysConsumer)
How sad for me if I had only inheritance, and thus was stuck being nothing more than a human
But thankfully, I can be all those things. However, I still cannot implement MiniDriver, but my day will come
Jose Botella
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You specialize a class with a subclass. An instance of the subclass "is an" instance of the class because it can receive at least the same messages(method invokations) that the superclass can. An instance of the subclass could be used wherever an instance of the superclass is acceptable --because it can receive the same messages--
When is it convenient to subclass? When you need a new class (subclass) that is very similar but not identical to an existing one (superclass). The subclass specializes the superclass: the subclass instance can override some of the method declared in superclass in a specialized way (providing implementation according to its type), it can add some state (fields) to that found in its superclass; or both.
It is a kind of composition. The composite class holds fields pointing to another objects. You need for your class (the composite) the abilites (methods) that another class holds. But they are not related. The referenced-to object "is not" an instance of the composite object. Thus do not use inheritance. Especially do not use inheritance to model different "states" of an object:
No -- PersonInLove extends Person
neither -- WorriedPerson extends Person
Use composition for that:
where mood is an instance of the class Mood. mood is "part" of the "composite" object person.
Both composition and inheritance have the same goal: reuse of code. The subclass reuse the code previously written in its superclass. The composite class reuse the code written in its part clas.
Gurus recommend composition over inheritance when both are possible. The subclass is highly coupled to its superclass. The composition is a more flexible approach. Obviously things clearly hierarquically related must be modelled with inheritance.
Consider Paul's rocket mass heater.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!