Aggregation - Composition

[Frederik Vanderhaegen]

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=oE ngine
}

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

[Bjorn Abelli]

"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=oE ngine
}

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 "aggregatio n" 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

[Jeff Louie]

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 "containmen t by ownership"
making Car an example of a composite class.

Containment can also be accomplished using references to external
objects. "Containmen t 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 ***

[Frederik Vanderhaegen]

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**********@D oNotSpam.hotmai l.com> schreef in bericht
news:OV******** ******@TK2MSFTN GP09.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=oE ngine
}

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 "aggregatio n" 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

[Bjorn Abelli]

"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 "specialize d concepts of associations".. . ;-)

As I said before:

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

// Bjorn A