Articles or Turorials on Aggregation??

[SenthilVel]

Hi

Can any one let me know the websites/Pdf for learning Aggragation in C#??

Thanks
Senthil

[Kevin Spencer]

The word "aggregation" simply means "group." So, you'll have to be more
specific about what sort of aggregation you're asking about.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.

"SenthilVel" <se******************@misyshealthcare.com> wrote in message
news:eG**************@TK2MSFTNGP14.phx.gbl...

Hi

Can any one let me know the websites/Pdf for learning Aggragation in C#??

Thanks
Senthil

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

Hi,
"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:uh**************@TK2MSFTNGP10.phx.gbl...

The word "aggregation" simply means "group." So, you'll have to be more
specific about what sort of aggregation you're asking about.

I do remember from my OOP classes in the univ that there was a clear
distinction between aggregation and composition, Aggregation is when a type
has a member variable of another type, but only store a reference. In such a
way that the inner instance can exist independently of the external, or
wrapper type. The destruction of the external one does not imply the
destruction of the internal.

In Composition the internal instance is created when the external one is
created and is destroyed at the same time.

C++ does implement both concepts very clearly.

In C# when you are using classes you have the aggregation by default.

The problem is when you want to use composition, in C# there is no way of
using composition with classes.
If you use a struct (value type) you do have composition as in C++.
Any comments are welcome, a few months ago somebody asked me that very same
question, how to implement aggregation and composition in C# and my
explanation was not very clear.


--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

[Jon Skeet [C# MVP]]

<"Ignacio Machin \( .NET/ C# MVP \)" <ignacio.machin AT
dot.state.fl.us>> wrote:

I do remember from my OOP classes in the univ that there was a clear
distinction between aggregation and composition, Aggregation is when a type
has a member variable of another type, but only store a reference. In such a
way that the inner instance can exist independently of the external, or
wrapper type. The destruction of the external one does not imply the
destruction of the internal.

In Composition the internal instance is created when the external one is
created and is destroyed at the same time.

C++ does implement both concepts very clearly.

In C# when you are using classes you have the aggregation by default.

The problem is when you want to use composition, in C# there is no way of
using composition with classes.
If you use a struct (value type) you do have composition as in C++.
Any comments are welcome, a few months ago somebody asked me that very same
question, how to implement aggregation and composition in C# and my
explanation was not very clear.

I would say that in C# the distinction becomes more a case of whether
that object itself is ever "let out" of the class - do you expose an
embedded list to clients, or do you just act as a proxy for it, asking
it for elements. Do you allow people to supply a list to start with?

If the "embedded" object is no longer accessible after the enclosing
instance is no longer accessible, then even if it hasn't actually been
garbage collected, it's been destroyed as far as anything else is
concerned. There's no longer any way to get at the data in it.

(This breaks down when you have finalizers, of course, but that's a
rare situation IMO.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

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

Hi,

If the "embedded" object is no longer accessible after the enclosing
instance is no longer accessible, then even if it hasn't actually been
garbage collected, it's been destroyed as far as anything else is
concerned. There's no longer any way to get at the data in it.

I think that you cannot assure a composition unless that the
enclosing(wrapper) type only expose value types from the composed type, as
soon as you expose it as reference you lose the composition as the calling
code can keep a reference to the member even after the wrapper is disposed.


--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

[Jon Skeet [C# MVP]]

<"Ignacio Machin \( .NET/ C# MVP \)" <ignacio.machin AT
dot.state.fl.us>> wrote:

If the "embedded" object is no longer accessible after the enclosing
instance is no longer accessible, then even if it hasn't actually been
garbage collected, it's been destroyed as far as anything else is
concerned. There's no longer any way to get at the data in it.

I think that you cannot assure a composition unless that the
enclosing(wrapper) type only expose value types from the composed type, as
soon as you expose it as reference you lose the composition as the calling
code can keep a reference to the member even after the wrapper is disposed.

Yes - so if you're composing including a List, you don't expose the
list itself, but you might have methods which effectively indexed the
list.

I'm not sure that it wouldn't count as composition if you exposed
immutable reference types (eg string) too though.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

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

HI,

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

<"Ignacio Machin \( .NET/ C# MVP \)" <ignacio.machin AT
dot.state.fl.us>> wrote:

> If the "embedded" object is no longer accessible after the enclosing
> instance is no longer accessible, then even if it hasn't actually been
> garbage collected, it's been destroyed as far as anything else is
> concerned. There's no longer any way to get at the data in it.
I think that you cannot assure a composition unless that the
enclosing(wrapper) type only expose value types from the composed type,
as
soon as you expose it as reference you lose the composition as the
calling
code can keep a reference to the member even after the wrapper is
disposed.

Yes - so if you're composing including a List, you don't expose the
list itself, but you might have methods which effectively indexed the
list.

Only if you expose the list as an indexer, if you just expose it as a
public property the calling code can keep a reference after the wrapper
instance is disposed.
I'm not sure that it wouldn't count as composition if you exposed
immutable reference types (eg string) too though.

Good question, I don't think that the OOP cover this case. At least I do not
remember being given this example in class.
My interpretation is that if you have something like

class C{
public string theStrig = "This is a string";
}

we can say that the member is assigned when the instance is created ( as in
composition ) but you can keep a reference to it after the wrapper is
disposed:

string s;
C c = new C;
s = c.theString;
c = null;
//I can keep using s as long as I keep a reference to it.


--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

[Joanna Carter [TeamB]]

"SenthilVel" <se******************@misyshealthcare.com> a écrit dans le
message de news: eG**************@TK2MSFTNGP14.phx.gbl...

| Can any one let me know the websites/Pdf for learning Aggragation in C#??

If you mean the OO concept of Aggregation, then that can be summed up in two
short descriptions.

Aggregation can be divided into two areas: Aggregation itself and
Composition.

Aggregation is where a class contains items that have a life of their own.
The containing class holds references to the items but those items are
responsible for their own lifetimes. e.g. a Car has components like Wheels,
Seats, Windows, but those components can be used in another vehicle or
replaced in the same vehicle.

class Wheel
{
...
}

class Car
{
// publicly available list that can be manipulated from outside of the Car
class
public List<Wheel> Wheels {...}
}

Composition is where a class contains items and is responsible for the
lifetime of the contained items. The contained items have no life or context
outside of the containing class. e.g. an Invoice has detail lines, but the
Invoice itself has to be asked to add lines to itself or remove lines from
itself. Detail lines cannot be instantiated outside of the Invoice of which
they are a part; you cannot move a line from one Invoice to another you
would have to copy the details over.

class InvoiceLine
{
internal InvoiceLine() {...} // hide constructor from public access.
...
}

class Invoice
{
// list is held privately and should not be exposed via a property
private List<InvoiceLine> lines = new List<InvoiceLine>();

// public methods that manage the internal list, wrapping only those
// methods that are necessary from outside of the Invoice

public InvoiceLine Add()
{
InvoiceLine newItem = new InvoiceLine();
lines.Add(newItem);
return newItem;
}

public void Remove(InvoiceLine line)
{
lines.Remove(line);
}

public void RemoveAt(int index)
{
lines.RemoveAt(index);
}

public Enumerator<InvoiceLine> GetLinesEnumerator()
{
return list.GetEnumerator();
}
}

Is that what you mean ?

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

[Jon Skeet [C# MVP]]

<"Ignacio Machin \( .NET/ C# MVP \)" <ignacio.machin AT

Yes - so if you're composing including a List, you don't expose the
list itself, but you might have methods which effectively indexed the
list.
Only if you expose the list as an indexer, if you just expose it as a
public property the calling code can keep a reference after the wrapper
instance is disposed.

I don't see how that would count as not exposing the list itself :)

I'm not sure that it wouldn't count as composition if you exposed
immutable reference types (eg string) too though.

Good question, I don't think that the OOP cover this case. At least I do not
remember being given this example in class.

Right.
My interpretation is that if you have something like

class C{
public string theStrig = "This is a string";
}

we can say that the member is assigned when the instance is created ( as in
composition ) but you can keep a reference to it after the wrapper is
disposed:

string s;
C c = new C;
s = c.theString;
c = null;
//I can keep using s as long as I keep a reference to it.

Indeed - but it doesn't affect the object. To me, the difference
between aggregation and composition is in terms of how clients can
affect the object. I'm not an expert though :)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

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

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

<"Ignacio Machin \( .NET/ C# MVP \)" <ignacio.machin AT

> Yes - so if you're composing including a List, you don't expose the
> list itself, but you might have methods which effectively indexed the
> list.
Only if you expose the list as an indexer, if you just expose it as a
public property the calling code can keep a reference after the wrapper
instance is disposed.

I don't see how that would count as not exposing the list itself :)

Ok, you got me there with the language :)
I was refering that you expose the elements , not the container.
IF you have a list of int exposed by an indexer, you can get the integers
but you cannot get a reference to the ArrayList, int[], or whatever class
you used.
Indeed - but it doesn't affect the object. To me, the difference
between aggregation and composition is in terms of how clients can
affect the object. I'm not an expert though :)

Agreed :- )
--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

[Alan Pretre]

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

If the "embedded" object is no longer accessible after the enclosing
instance is no longer accessible, then even if it hasn't actually been
garbage collected, it's been destroyed as far as anything else is
concerned. There's no longer any way to get at the data in it.

I think it is a matter of ownership, simply. If the "enclosing" object, so
to speak, owns the reference*, it is responsible for the lifetime of it. If
not, it is simply using it and the lifetime of the referenced object is
independent of the container. Would you agree?

Ref.: GoF p.22

*Note: Ownership can be transferred to another container, but there can only
be at most 1 owner.

-- Alan

[Jon Skeet [C# MVP]]

Alan Pretre <no@spam> wrote:

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

If the "embedded" object is no longer accessible after the enclosing
instance is no longer accessible, then even if it hasn't actually been
garbage collected, it's been destroyed as far as anything else is
concerned. There's no longer any way to get at the data in it.

I think it is a matter of ownership, simply. If the "enclosing" object, so
to speak, owns the reference*, it is responsible for the lifetime of it. If
not, it is simply using it and the lifetime of the referenced object is
independent of the container. Would you agree?

Ref.: GoF p.22

*Note: Ownership can be transferred to another container, but there can only
be at most 1 owner.

It depends exactly what is meant by ownership. Responsibility for
lifetime? Responsibility for data?

I guess the question I'd like to ask is what *useful* distinction can
be made between the two in C#. Is there some way of interpreting the
patterns so that in some cases we could describe the usage as
aggregation and in some we could call it composition? Or do we need to
invent a new term for when we expose immutable data?

Suppose instead of exposing an actual string, we exposed the length as
one property, and allowed indexing of the string. A client could easily
reconstruct the string - they would be functionally equivalent,
wouldn't they? Would one be composition and the other aggregation?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Alan Pretre]

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

It depends exactly what is meant by ownership. Responsibility for
lifetime? Responsibility for data?

I guess the question I'd like to ask is what *useful* distinction can
be made between the two in C#.
Yes, I agree this is hard to see in C#. Perhaps ownership concept is most
useful with IDisposable objects, since the object would usually be disposed
of once and only once (ignoring resurrection).

It's easier to see in C++ where the owner (owner only) does an explicit
delete on the reference.
Is there some way of interpreting the
patterns so that in some cases we could describe the usage as
aggregation and in some we could call it composition?
I think in C# it is a matter of intent only.
Or do we need to
invent a new term for when we expose immutable data?

constness?

My understanding of ownership is that it does not imply immutability, but
simply responsibility for lifetime.

Though if immutability is a requirement then obviously the way the enclosed
object is exposed to the outside world is affected, as in your example.

-- Alan

[Alan Pretre]

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Alan Pretre <no@spam> wrote:

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Is there some way of interpreting the
patterns so that in some cases we could describe the usage as
aggregation and in some we could call it composition?

I think Composition implies non-ownership of the consituent objects. Think
of free floating autonomous objects of various flavors, and a "big" object
that comes along and picks-and-chooses which flavors he wants to contain at
that moment. The sum of the composed objects determines the characteristics
of the "big" object. The "big" object is free to replace any of the
contained objects with the other ones. He is not responsible for creating
or destroying these other ones. This implies well-defined interfaces.

An example, I think, of Composition is the use of plug-ins. Kind of like
Mr. Potato Head.

Aggregation would be the opposite of that. The "big" object is responsible
for creating and destroying the objects, whatever that means. Though the
contained objects may be exposed to the outside world, immutable or not,
their *intent* is to be dedicated to the "big" object.

-- Alan

[Joanna Carter [TeamB]]

"Alan Pretre" <no@spam> a écrit dans le message de news:
O0**************@TK2MSFTNGP14.phx.gbl...

| I think Composition implies non-ownership of the consituent objects.
Think
| of free floating autonomous objects of various flavors, and a "big" object
| that comes along and picks-and-chooses which flavors he wants to contain
at
| that moment. The sum of the composed objects determines the
characteristics
| of the "big" object. The "big" object is free to replace any of the
| contained objects with the other ones. He is not responsible for creating
| or destroying these other ones. This implies well-defined interfaces.
|
| Aggregation would be the opposite of that. The "big" object is
responsible
| for creating and destroying the objects, whatever that means. Though the
| contained objects may be exposed to the outside world, immutable or not,
| their *intent* is to be dedicated to the "big" object.

No, I am sorry, but you are totally wrong, Composition implies ownership,
aggregation implies non- ownership.

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

[Alan Pretre]

"Joanna Carter [TeamB]" <jo****@not.for.spam> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

"Alan Pretre" <no@spam> a écrit dans le message de news:
O0**************@TK2MSFTNGP14.phx.gbl...
No, I am sorry, but you are totally wrong, Composition implies ownership,
aggregation implies non- ownership.

From GoF, p.22
"Aggregation implies that one object owns or is responsible for another
object. Generally we speak of an object having or being part of another
object. Aggregation implies that an aggregate object and its owner have
identical lifetimes."

From GoF, p.19
"Object composition is defined dynamically at run-time through objects
acquiring references to other objects. Composition requires objects to
respect each others' interfaces..."

*By GoF (Gang of Four) I mean the book, Design Patterns by Gamma, Helm,
Johnson and Vlissides

-- Alan

[Joanna Carter [TeamB]]

"Alan Pretre" <no@spam> a écrit dans le message de news:
u6*************@TK2MSFTNGP15.phx.gbl...

| From GoF, p.22
| "Aggregation implies that one object owns or is responsible for another
| object. Generally we speak of an object having or being part of another
| object. Aggregation implies that an aggregate object and its owner have
| identical lifetimes."

I'll see your GoF and raise you a UML spec :-))

7.3.2 AggregationKind (from Kernel)
AggregationKind is an enumeration type that specifies the literals for
defining the kind of aggregation of a property.
Generalizations
None
36 UML Superstructure Specification, v2.0
Description
AggregationKind is an enumeration of the following literal values:
• none Indicates that the property has no aggregation.
• shared Indicates that the property has a shared aggregation.
• composite Indicates that the property is aggregated compositely, i.e., the
composite object has responsibility for the
existence and storage of the composed objects (parts).

| From GoF, p.19
| "Object composition is defined dynamically at run-time through objects
| acquiring references to other objects. Composition requires objects to
| respect each others' interfaces..."

Object Composition here is talking about the composition of an object; IOW,
a class is made up from references to different types, not the Composite
relationship, this is a subtle difference in the English language that can
be mistaken by a non-native speaker.

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

[Alan Pretre]

"Joanna Carter [TeamB]" <jo****@not.for.spam> wrote in message
news:u%****************@TK2MSFTNGP15.phx.gbl...

Object Composition here is talking about the composition of an object;
IOW,
a class is made up from references to different types, not the Composite
relationship, this is a subtle difference in the English language that can
be mistaken by a non-native speaker.

Yes, well there appears to be some confusion in nomenclature.

Again, for example,

http://atomicobject.com/training/tra...o-quality.page
(Section Inheritance and Composition)
"In C++ we can make a useful distinction between aggregation and composition
(aka association). Aggregation is done by value (life times the same between
whole/part). Composition is done by reference (reference or pointer,
lifetimes de-coupled) so that the object being referred to can *change* at
run-time."

Emphasis added by me.

http://atomicobject.com/training/tra...gregation.page
(1st paragraph)
Different authors use different terms for the idea of containment. UML has a
very specific use (and different symbols) of the terms aggregation and
composition, though this is not necessarily consistent with OO authors. For
the record, UML aggregation is "weak containment", usually implemented with
pointers, and the symbol is an open diamond. Composition is "strong
containment", implemented by value, and the symbol is a filled diamond.

(6th paragraph)
By value means that the lifetimes of the objects are exactly the same; they
are born and die at the same time; they are inseparable during their
lifetimes. Aggregation by value cannot be cyclic: one object is the whole,
one the part.

(7th paragraph)
By reference de-couples the lifetimes of the two objects. The whole may not
have a part, or it may have a different part at different times. Different
wholes may share the same part. De-allocating the whole won't automatically
de-allocate the part. Aggregation by reference allows for the part to be
aware of its whole.
There are more references I could site but I will stop here. I also found
references describing it as you have.

-- Alan

[Jeff Louie]

I think the problem is that according to Booch Aggregation is a whole
part
relationship. Aggregation in turn can be implemented using containment
by
ownership OR it can be implemented using containment by reference (OO
Analysis and Design 1994).

http://www.geocities.com/Jeff_Louie/OOP/oop7.htm

In turn, composition is defined as a special form of Aggregation with
strong
ownership and conincident lifetime of the parts by the whole (UML
Language
User Guide 1999).

http://www.geocities.com/Jeff_Louie/OOP/oop12.htm

So to be simple one could avoid the terms Aggregation and Composition
and
stick to the terms Containment by Reference and Contaiment by Ownership.
However, the distinction between these terms is less clear in a garbage
collected environment.

http://www.geocities.com/Jeff_Louie/oop27.htm

Regards,
Jeff

*** Sent via Developersdex http://www.developersdex.com ***

[Jon Skeet [C# MVP]]

Jeff Louie <je********@yahoo.com> wrote:

<snip>

So to be simple one could avoid the terms Aggregation and Composition
and stick to the terms Containment by Reference and Contaiment by Ownership.
However, the distinction between these terms is less clear in a garbage
collected environment.

And given the problems people already have due to the word "reference"
being overloaded with parameters being passed by reference or being
references passed by value, I suspect it would only introduce more
confusion.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Joanna Carter [TeamB]]

"Alan Pretre" <no@spam> a écrit dans le message de news:
Oo***************@TK2MSFTNGP15.phx.gbl...

| Yes, well there appears to be some confusion in nomenclature.

Hmmm, this is interesting but disturbing. I have always assumed the UML spec
to be the authoritative source, but can see where the confusion has
occurred. Here we have a single source of teaching on the subject stating
both side of the argument at the same time !!!

If I were you, I would take the UML spec as *the* way as it has not changed
for at least ten years that I am aware of. Certainly if you are using UML to
communicate design, anyone else that knows UML should understand that
aggregation = ref and composition = value.

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

[Joanna Carter [TeamB]]

"Jon Skeet [C# MVP]" <sk***@pobox.com> a écrit dans le message de news:
MP************************@msnews.microsoft.com...

| And given the problems people already have due to the word "reference"
| being overloaded with parameters being passed by reference or being
| references passed by value, I suspect it would only introduce more
| confusion.

Dontcha just love it when two people can talk the same language and hear two
different things ?
OK, so maybe we should all talk UML :-))

white diamond = loose containment
black diamond = owned containment

Joanna

--
Joanna Carter [TeamB]
Consultant Software Engineer

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

Hi,

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Jeff Louie <je********@yahoo.com> wrote:

<snip>

So to be simple one could avoid the terms Aggregation and Composition
and stick to the terms Containment by Reference and Contaiment by
Ownership.
However, the distinction between these terms is less clear in a garbage
collected environment.

And given the problems people already have due to the word "reference"
being overloaded with parameters being passed by reference or being
references passed by value, I suspect it would only introduce more
confusion.

And do not forget "object " depending of who and where it's said it means
either instance of type

[Jeff Louie]

No. It cannot _introduce_ more confusion since "containment by
reference" is
the exact wording used by Booch well over 16 years ago in his discussion
of
Aggregation :)

Regards,
Jeff

And given the problems people already have due to the word "reference"

being overloaded with parameters being passed by reference or being
references passed by value, I suspect it would only introduce more
confusion.<

*** Sent via Developersdex http://www.developersdex.com ***