composition and aggregation ???

[cmrchs]

Hi,

how do I implement aggregation and how composition in C# ?
When I say : an Airplane has a Pilot then I use aggregation but
when I say : an Airplane has a Cockpit then I use composition.
How do I implement the difference in C# ?

Here's what I try :

class Pilot
{....}

class Cockpit
{...}

class Airplane
{
Pilot p;
Cockpit c;

public Airplane()
{
p = new Pilot(); // must be aggregated
c = new Cockpit(); // must be composed
}
}

I don't see any difference. Is there a way to create the distinction ?

thanks
Chris

**********************************************************************
Sent via Fuzzy Software @ http://www.fuzzysoftware.com/
Comprehensive, categorised, searchable collection of links to ASP & ASP.NET resources...

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

There is no way of doing it, these are logic interpretation concepts that
are expressed in tha same way.

Why you want to express them in different ways?

cheers,

 

[cmrchs]

hi Ignacio,

cause in C++ you can do it by :

class Airplane
{
Pilot *p; // aggregation
Cockpit c; // embedded object, thus composition

public Airplane()
{
p = new Pilot();
}
}

but you say it doesn't matter then ?
for the pilot OK since in C# reference variables are used anyway, but I was wondering for the cockpit.
In C# is the cockpit not really 'built-in' in the Airplane-object anymore since a reference is used then as well.
How can I make sure then that lifetime of the supposed embedded Cockpit will not extend that of the Airplane ?

thanks
Chris

**********************************************************************
Sent via Fuzzy Software @ http://www.fuzzysoftware.com/
Comprehensive, categorised, searchable collection of links to ASP & ASP.NET resources...

 

[Joanna Carter \(TeamB\)]

how do I implement aggregation and how composition in C# ?
When I say : an Airplane has a Pilot then I use aggregation but
when I say : an Airplane has a Cockpit then I use composition.
How do I implement the difference in C# ?

Aggregation is when a containing object holds references to other objects,
but those other objects have a life of their own.

Composition is when other objects are owned by a containing object and their
lifetime is managed by the containing object.

I can't make your example work as both a Pilot and a Cockpit can be moved
from one plane to another; ergo they are both aggregations.

The essential difference is the lifetime management of child objects

// Aggregation
class StockLocation
{
...
public void AddProduct(Product p) {...}
}

You can create Product instances outside of the StockLocation and you can
move them from one location to another.

// Composition
class Invoice
{
...
public InvoiceLine AddLine() {...}
}

You have to ask the Invoice to create an instance of an Invoice Line.

Does this help ?

Joanna

 

[Bruce Wood]

Correct me if I'm wrong, but part of the difference here (in C#, at
least) has to do with the functionality that the enclosing object
offers to its callers.

To go back to the airplane and cockpit example (composition, the
problematic case), you want the airplane to create its own cockpit
(possibly using information passed on the constructor), and then the
Cockpit method of the Airplane has no setter:

public Cockpit Cockpit
{
get { return this.cockpitComponent; }
}

....because, if it offered a setter, then you could get the cockpit from
one plane and assign it to another, breaking the rules of composition.

The fact that C# actually stores the cockpit as a separate heap object,
and that airplane has only a reference to it, doesn't matter so much as
how you design your airplane object to ensure that callers can't assign
cockpits to airplanes by any means.

If you structure the enclosing object in this way--creates its own
child object, and won't let any caller assign a new child object--then
what you have, in effect, is composition. If you allow callers to
assign a child object, then what you have, in effect, is aggregation.