469,291 Members | 1,802 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,291 developers. It's quick & easy.

Aggregation - Composition

Hi,

Can anyone explain me the difference between aggregation and composition?
I know that they both are "whole-part" relationships and that composition
parts are destroyed when the composition whole is destroyed.
Under a "whole-part" relationship I understand the following:
the whole can't exists without the parts, but can the parts exist without
the hole?
f.e.: a car can't exist without an engine
private engine _Engine
public car(engine oEngine){
this._Engine=oEngine
}

but, is it possible to create an engine without that a car has been
created?

Is it possible to provide me a code sample because I don't have a clue how
to implement this and a sample says more than a 1000 words.

Please correct me if I'm wrong.

Thanks in advance

Frederik
Nov 17 '05 #1
4 14172

"Frederik Vanderhaegen" wrote...
Can anyone explain me the difference between aggregation and composition?
I know that they both are "whole-part" relationships and that composition
parts are destroyed when the composition whole is destroyed.
Under a "whole-part" relationship I understand the following:
the whole can't exists without the parts, but can the parts exist without
the hole?
f.e.: a car can't exist without an engine
private engine _Engine
public car(engine oEngine){
this._Engine=oEngine
}

but, is it possible to create an engine without that a car
has been created?


That's both the point and the question.

Both association and composition as OO concepts are just that, *concepts* to
be used at the "conceptual level" when you're designing your application.

The "car-engine" example as such isn't that good as an example, as you can
decide to go either way, or rather, it depends on what you want to allow.

It also seems that you're somewhat confused to what these concepts actually
means.

Composition: When you "destroy" the whole, the parts are also destroyed.
Aggregation: When you "destroy" the whole, the parts can still continue to
exist.

A pretty clear (and classic) example of "aggregation" is a course with
students. You can say that the course "aggregates" its students, but when
you delete the course from the system (e.g. it's finished), the students
themselves remain, e.g. as students in other courses.

It's harder to find the need for "true" composition, as you in almost any
case can find some possiblity to "reuse" the parts. But that's why they're
just "concepts". If you don't find a need to keep the engine when the car
crashed, that's your choice... ;-)

An example I sometimes use is a hotel with rooms. The hotel is composed of
rooms, as they won't exist without the hotel.

Implementation-wise...
They're only references anyway... ;-)

HTH

// Bjorn A

Nov 17 '05 #2
Containment by ownership:
class Car : Vehicle
{
Radio r= new Radio();
}

An instance of Car contains an instance of a Radio so that the lifetimes
of the radio and car are intertwined. This is "containment by ownership"
making Car an example of a composite class.

Containment can also be accomplished using references to external
objects. "Containment by reference" can be expressed in code thusly:

class Radio
{
...
}
class Vehicle
{
...
}
class Car : Vehicle
{
private Radio r;
public Car(Radio r) {
...
this.r= r;
}
}
You can then create an instance of Car like this:

class Class1
{
[STAThread]
static void Main(string[] args)
{
Radio r= new Radio();
Car c= new Car(r);
}
}

A real world example would be a custom collection. Your custom class
could contain the actual collection by ownership and provide type safe,
null safe setters and getters.

If you then want to pass a read only version of the custom class, you
would create a new class that wraps the read write collection and
provides only getters, a so called immutable class. You would _not_ need
to copy the collection, but could simply pass a reference to the
existing custom class. The read only class would use containment by
reference and avoid the overhead of a deep copy of the collection.

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***
Nov 17 '05 #3
Now I understand the difference between aggregation and composition but what
do you mean *concepts*?
Is there no way to implement aggregation and composition? Do they behave
like an association?
As you can read I'm very new in OO, so any help is welcome :$

thx.

"Bjorn Abelli" <bj**********@DoNotSpam.hotmail.com> schreef in bericht
news:OV**************@TK2MSFTNGP09.phx.gbl...

"Frederik Vanderhaegen" wrote...
Can anyone explain me the difference between aggregation and composition?
I know that they both are "whole-part" relationships and that composition
parts are destroyed when the composition whole is destroyed.
Under a "whole-part" relationship I understand the following:
the whole can't exists without the parts, but can the parts exist
without the hole?
f.e.: a car can't exist without an engine
private engine _Engine
public car(engine oEngine){
this._Engine=oEngine
}

but, is it possible to create an engine without that a car
has been created?


That's both the point and the question.

Both association and composition as OO concepts are just that, *concepts*
to be used at the "conceptual level" when you're designing your
application.

The "car-engine" example as such isn't that good as an example, as you can
decide to go either way, or rather, it depends on what you want to allow.

It also seems that you're somewhat confused to what these concepts
actually means.

Composition: When you "destroy" the whole, the parts are also destroyed.
Aggregation: When you "destroy" the whole, the parts can still continue to
exist.

A pretty clear (and classic) example of "aggregation" is a course with
students. You can say that the course "aggregates" its students, but when
you delete the course from the system (e.g. it's finished), the students
themselves remain, e.g. as students in other courses.

It's harder to find the need for "true" composition, as you in almost any
case can find some possiblity to "reuse" the parts. But that's why they're
just "concepts". If you don't find a need to keep the engine when the car
crashed, that's your choice... ;-)

An example I sometimes use is a hotel with rooms. The hotel is composed of
rooms, as they won't exist without the hotel.

Implementation-wise...
They're only references anyway... ;-)

HTH

// Bjorn A

Nov 17 '05 #4
"Frederik Vanderhaegen" wrote...
Now I understand the difference between aggregation and
composition but what do you mean *concepts*?
With "concepts" I mean that it's something you use at the conceptual level
to try to understand how different object will relate to each other, i.e. in
the design phase before you start to code.
Is there no way to implement aggregation and composition?
There's of course ways to implement aggregation and composition differently,
but in most cases simple aggregation will suffice for the patterns where you
conceptually want a composition.

Let's look at an example:

==============================================

class Hotel
{
private ArrayList rooms = new ArrayList();

public void CreateRoom()
{
rooms.Add(new Room());
}

private class Room { }
}

==============================================

The construction above could be seen as a strict
kind of composition, but to encapsulate the class
Room in this way can be impractical.

==============================================
public class Hotel
{
private ArrayList rooms = new ArrayList();

public void AddRoom(Room r)
{
rooms.Add(r);
}
}

public class Room {}

==============================================
The latter example can *still* be used for
composition, as long as the Rooms you instantiate
*only* will be referenced from the Hotel's
ArrayList of rooms.

The main difference is that you've opened up
for situations where Rooms *can* be referenced
from other places as well.

If you *conceptually* want a composition, but the
latter construct, just make sure the Rooms only
will be used within the Hotels.

==============================================
Do they behave like an association?
As you can read I'm very new in OO, so any help is welcome :$


In both cases they're "specialized concepts of associations"... ;-)

As I said before:
Implementation-wise...
They're only references anyway... ;-)


// Bjorn A
Nov 17 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by DKode | last post: by
4 posts views Thread by cmrchs | last post: by
11 posts views Thread by aaj | last post: by
23 posts views Thread by SenthilVel | last post: by
7 posts views Thread by Bruce One | last post: by
2 posts views Thread by Gary Wessle | last post: by
6 posts views Thread by Jeff | last post: by
4 posts views Thread by Salman | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by harlem98 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.