S
SenthilVel
Hi
Can any one let me know the websites/Pdf for learning Aggragation in C#??
Thanks
Senthil
Can any one let me know the websites/Pdf for learning Aggragation in C#??
Thanks
Senthil
K
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.
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.
I
Ignacio Machin \( .NET/ C# MVP \)
Hi,
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.
Kevin Spencer said:
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.
J
Jon Skeet [C# MVP]
<"Ignacio Machin \( .NET/ C# MVP \)" <ignacio.machin AT
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.)
dot.state.fl.us> said:
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.)
I
Ignacio Machin \( .NET/ C# MVP \)
Hi,
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.
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.
J
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.
I'm not sure that it wouldn't count as composition if you exposed
immutable reference types (eg string) too though.
dot.state.fl.us> said:
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.
I
Ignacio Machin \( .NET/ C# MVP \)
HI,
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.
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.
Jon Skeet said:
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.
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.
J
Joanna Carter [TeamB]
"SenthilVel" <[email protected]> a écrit dans le
message de news: (e-mail address removed)...
| 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
message de news: (e-mail address removed)...
| 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
J
Jon Skeet [C# MVP]
<"Ignacio Machin \( .NET/ C# MVP \)" <ignacio.machin AT
I don't see how that would count as not exposing the list itself
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
I don't see how that would count as not exposing the list itself
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
I
Ignacio Machin \( .NET/ C# MVP \)
Jon Skeet said:<"Ignacio Machin \( .NET/ C# MVP \)" <ignacio.machin AT
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 :- )
A
Alan Pretre
Jon Skeet said:
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
J
Jon Skeet [C# MVP]
Alan Pretre said:
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?
A
Alan Pretre
Jon Skeet said:
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.
I think in C# it is a matter of intent only.
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
A
Alan Pretre
Jon Skeet said:
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
J
Joanna Carter [TeamB]
"Alan Pretre" <no@spam> a écrit dans le message de (e-mail address removed)...
| 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
| 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
A
Alan Pretre
Joanna Carter said:
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
J
Joanna Carter [TeamB]
"Alan Pretre" <no@spam> a écrit dans le message de (e-mail address removed)...
| 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
| 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
A
Alan Pretre
Joanna Carter said:
Yes, well there appears to be some confusion in nomenclature.
Again, for example,
http://atomicobject.com/training/training-material/oo-notes/oo-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/training-material/oo-notes/aggregation.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
J
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
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
J
Jon Skeet [C# MVP]
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.