aggregation and composition

Aggregation is dynamic relationship, with composition the relation is static. These also imply (but not guarantee) that linkage in composition is bi-directional and uni-directional with aggregation, but in practice this is only a rule of thumb.

composition

A car is composed of Chassis, Engine and Wheels without all these it is not really a car.

aggregation

A car is aggregated with a spoiler and go-faster strips, without these it is still a car.

MartinS. at 2007-7-7 1:36:24 >

Hi, All,

I would like to join your discussion. In OODA and UML, there is no relationship called "composition relationship". The three well-known relationships are (1) inheritance relationship (i.e., "is" relationship), (2) association relationship ("use" relationship) and (3) aggregation relationship ("has" relationship), which is also called containment relationship. The association relationship and aggregation relationship differ in whether the relationship has a ownership or not. For instance, a car can use a gas station to fill up its tank, but it does not own the gas station. A mower can also use the gas station for fuel. Therefore, it is an association relationship. However, a car has (or owns) an engine, which is an aggregation relationship.

I think that composition means different thing. In Gamma et al's "Design Patterns" book, when they talked about code reuse, they mentioned "Inheritance versus Compsition" (p. 18). They favor object composition other than inheritance. Clearly, in their book, object composition means reusing functionality at run-time through objects acquring references to other objects, that is, through the association and aggregation relationships.

Thanks.

Tommy

MuranoYin at 2007-7-7 1:36:24 >

> You are correct that aggregation and composition are

> both "has-a" relationships. The difference is that

> there is a strong link between the parent and

> child classes in composition.

> There is a weak link between the parent and

> child classes in aggregation.

>

> If you destroy the parent class in an aggregation

> (weak) relationship, the child classes can survive on

> their own.

>

> If you destroy the parent class in a composition

> (strong) relationship, the child classes must be

> destroyed also.

>

The difference between the two was pointed out quite simply by me in reply#3. However I dont understand how does inheritance come into the picture over here. We are discussing .........

HELLO...........

> An example :

> In aggregation - Tree is the parent class and Leaf is

> the child class. When you destroy the parent (Chop

> down the tree) some Leaves are still lying on the

> ground. I.E. the child (Leaf) can survive without its

> parent - as an entity in its own right.

>

> In composition - Car is the parent class and Engine is

> the child class.

> When you destroy the parent (Crush the car) the child

> class is destroyed too (engine is also crushed). I.E.

> the child class (engine) cannot survive as an entity

> on its own without the parent.

>

> > The instance of aggregated class can be shared by

> many

> > other classes. While those classes are deleted, the

> > instance of aggreated class won't be deleted.

> > In the other hand, the instance of composited class

> > can only be used by one other class. While that

> class

> > is deleted. The composited class will also be

> deleted.

>

nome02 at 2007-7-7 1:36:24 >

I think for java users, this can be an example of composition (Carburetor) and aggregation (Person) for a car scenario.

public class Car

{

private Carburetor carb;

public Parson per;

public Person CrushCar()

{

// destroy Carburetor here, and return a clone of Person

return per.clone();

}

}

When car is crushed, person will jump out of it somehow, making a clone of itself ( see the method CrushCar() ), and client can now let the same Person sit in another Car. Making clone will assure that garbage collector will not remove this copy of Person when instance of Car goes out of scope.

Note: Person class must be cloneable.

I have not tested this code, it's just a quick example.

Let me know if I am wrong.

Khawar.

Kazim_sida at 2007-7-18 15:50:00 >

> > You are correct that aggregation and composition

> are

> > both "has-a" relationships. The difference is that

> > there is a strong link between the parent

> and

> > child classes in composition.

> > There is a weak link between the parent and

> > child classes in aggregation.

> >

> > If you destroy the parent class in an aggregation

> > (weak) relationship, the child classes can survive

> on

> > their own.

> >

> > If you destroy the parent class in a composition

> > (strong) relationship, the child classes must be

> > destroyed also.

> >

>

> The difference between the two was pointed out quite

> simply by me in reply#3. However I dont understand

> how does inheritance come into the picture over here.

> We are discussing .........

>

> HELLO...........

Hello! CelticPhantom is not talking about inheritance. he/she is talking about parent child relationships in a tree structure of objects...

The key to your answer is that you don't consider the case where you may have a tree/graph of objects. The Car/wheel example is trivial, most real applications have much more complicated data structures. If all node objects in the tree have are associated with a composition adornment then for any parent you delete/remove/unlink/make-eligible-for-gc then you should also unlink all of its children (and so on...). IMO it is not "simple".

al_bagehota at 2007-7-18 15:50:00 >

There is a lot of confusion here basically as people are combining definition and implementation

Definition:

Both used to model one to many or many to many relationships

Composition owns the life cycle of classes, i.e. if owner is destroyed all its composite classes will be destroyed

Aggregation is just holding a reference to the aggregated classes i.e. Even if the owner is destroyed the aggregated classes can be still available.

Note : The following code is just written to explain the problem,it can be implemented in many ways and it is not a tested code to

Design/Implementation:

This relation ship between the classes is very context sensitive, depends on the design.

Example: The relation between car and its tires can be implemented using Composition or Aggregation

Aggregation:

If in the spec the tires can exists with out a car it can be implemented using aggregation (ex A car manufacturer has a separate list of Tires, and cars)

Public Tire{ }

Public Car {

Private Vector tires = new Vector(4);

Public void addTire(Tire tt){tires.add(tires);}

}

//here Manufacturer as well as Car has a reference to the Tire

Public Manufacturer {

Public static void main (String args [])

{

Car c = new Car();

Tire t1 = new Tire();Tire t1 = new Tire();

c.addTire(t1);c.addTire(t2);

c = null;

//at this statement car is destroyed but not t1 and t2

}

}

Composition:

If in the spec the tires cannot exists with out a car (Ex A car deler does not worry maintain a list of tires , what matters to him is just the Car which has tires)

Public Car {

Car()

{

Tire t1 = new Tire();Tire t1 = new Tire();

tires.add(t1);tires.add(t2);

}

Private Vector tires = new Vector(4);

private Tire{ }

}

//here Dealer has only reference to Car

public Dealer {

public static void main(String args[])

{

Car c = new Car();

c = null;//at this statement both c as well as

}

}

seshaveeraa at 2007-7-18 15:50:00 >

I like Martin Fowler's definition in "UML Distilled":

"Aggregation is the part-of relationship. It's like saying a car has an engine and wheels as its parts."

"Composition is a stronger variety of aggregation. The part object may belong to only one whole; further, the parts are usually expected to live and die with the whole. Any deletion of the whole is considered to cascade to the parts."

duffymoa at 2007-7-18 15:50:00 >

Hi Paul,

"technical-based" - what else is there?

I'm saying that I seem to be stuck in the same rut that you've put OMG/UML into - I can't conceive of a situation where the cascade dynamic would switch in mid-stream.

But if you must have this kind of behavior, there might be a way to do it.

You could have an interface that has two different concrete implementations: one that would implement aggregation semantics and another that would use composition. You could decide which one you wanted to use at runtime.

There's also a GOF Pattern called State where an object can appear to change its type on the fly:

http://www.fluffycat.com/java/JavaNotes-GoFState.html

Maybe these would allow you to do what you want. I'd say that if these express what you're getting at, then it's possible to capture it in UML. - MOD

duffymoa at 2007-7-18 15:50:00 >