kgreddy
asked on
Composition, Aggregation are they synonymous?
I would like to know if composition and Aggregation
are synonymous.
And would like to understand this concept with a
small example
are synonymous.
And would like to understand this concept with a
small example
I'm assuming that you mean containment instead of composition. Containment and aggregation are somewhat similar. They both involve one object (the outer object) containing another object (the inner object). In aggregation, the methods of the inner object are exposed directly to the client by the outer object. In containment, the outer object provides stubs for the inner objects methods and calls to those stubs are forwarded to the inner object.
ASKER
Nietod :
I have increased the points to 50.
Actually, I do not have many points in my account that
is why I am cautious about this.
SampsonC :
I could not follow you explanation.
Can you please give a small example?
I have increased the points to 50.
Actually, I do not have many points in my account that
is why I am cautious about this.
SampsonC :
I could not follow you explanation.
Can you please give a small example?
ASKER
Nietod :
I have increased the points to 50.
Actually, I do not have many points in my account that
is why I am cautious about this.
SampsonC :
I could not follow you explanation.
Can you please give a small example?
I have increased the points to 50.
Actually, I do not have many points in my account that
is why I am cautious about this.
SampsonC :
I could not follow you explanation.
Can you please give a small example?
>> you mean containment instead of composition.
No. I think he means composition. composition and aggregation (sp?) are structural design patterns. containment is a OOP principle.
No. I think he means composition. composition and aggregation (sp?) are structural design patterns. containment is a OOP principle.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
As you can see the two are very similar, they differ only in how tightly the object is "bound" to the objects used in its implimentation. And that is not necessarily an easy distinction to make.
Some clear C++ examples might be that a class that contains objects as data members is definitely a composite. These data members are very closely associated with the class. They are created when an object of the class is created, they are destoyed when the object is destroyed. They cannot be changed during the lifetime of the object (They can be changed in value, but they cannot be changed for another object. i.e. if an object has to keep its actual data member, it can't switch it for a data member stored in another object. That might be so obvious that it seems strange to mention, but I mention it because it is not necessarily true for aggregates.).
Another example of a C++ composite would be a derived class. The bar class, especially if there are multiple bases would make the derived class act like a composte. And again, as in the case of data members, the "composing objects" are very tightly bound to the composite object.
continues
Some clear C++ examples might be that a class that contains objects as data members is definitely a composite. These data members are very closely associated with the class. They are created when an object of the class is created, they are destoyed when the object is destroyed. They cannot be changed during the lifetime of the object (They can be changed in value, but they cannot be changed for another object. i.e. if an object has to keep its actual data member, it can't switch it for a data member stored in another object. That might be so obvious that it seems strange to mention, but I mention it because it is not necessarily true for aggregates.).
Another example of a C++ composite would be a derived class. The bar class, especially if there are multiple bases would make the derived class act like a composte. And again, as in the case of data members, the "composing objects" are very tightly bound to the composite object.
continues
An aggregate is more "loosely bound" than a composite. For example, if a class contains pointers to other objects that it manipulates it tends to be considered to be an aggregate. Especially if those objects that are manipulated can be changed using the interface to the aggregate object. For example, if you had a class that represents a compiler and that class mantains a pointer to a parser object used to parse the source code. And if the client could change the parser object used by the compiler object (like to configure the parser object, or to actually change it to a totally different parser object), this would pretty clearly be a case of aggregation.
Now aggregation doesn't just mean storing a pointer to some object and using the pointer at times. It implies that the aggregate does manage the other object(s) as well. In particular, it may be responsible for deleting that object.
As you can see, the boundary between the two can be indistinct. What about an object that stores a pointer to another object, automatically creates and destroys that object, and doesn't provide any interface for the client to directlly affect that other object. Is this an aggregate or a composite? I say composite, but I bet that half the experts out there would dissagree.
Now aggregation doesn't just mean storing a pointer to some object and using the pointer at times. It implies that the aggregate does manage the other object(s) as well. In particular, it may be responsible for deleting that object.
As you can see, the boundary between the two can be indistinct. What about an object that stores a pointer to another object, automatically creates and destroys that object, and doesn't provide any interface for the client to directlly affect that other object. Is this an aggregate or a composite? I say composite, but I bet that half the experts out there would dissagree.
>> I do not have many points in my account
Sorry. I didn't mean to be greedy, but the answer requires LOTS of typing, as you can see.
Sorry. I didn't mean to be greedy, but the answer requires LOTS of typing, as you can see.
ASKER
Yeah, I meant composition and not containment.
Thanks Nietod for your explanation.
Actually if I look at the examples where composition or
Aggregation is used, they might look similar to me sometimes
but from your explanation, what I understand is when I use
composition, where I may use objects of other classes to create
my object but the client may not even know that it
is made up of other objects. It's implementation is kind of hidden
from the client who using this composite class.
But in case of Aggregation, my object though it uses other objects,
it is known to the client and also client has acess to the interface of
the object which is used to create my object.
Did I get it right?
I want to give points to Nietod.
Do I have to first reject SampsonC's answer?
Thanks Nietod for your explanation.
Actually if I look at the examples where composition or
Aggregation is used, they might look similar to me sometimes
but from your explanation, what I understand is when I use
composition, where I may use objects of other classes to create
my object but the client may not even know that it
is made up of other objects. It's implementation is kind of hidden
from the client who using this composite class.
But in case of Aggregation, my object though it uses other objects,
it is known to the client and also client has acess to the interface of
the object which is used to create my object.
Did I get it right?
I want to give points to Nietod.
Do I have to first reject SampsonC's answer?
ASKER
Yeah, I meant composition and not containment.
Thanks Nietod for your explanation.
Actually if I look at the examples where composition or
Aggregation is used, they might look similar to me sometimes
but from your explanation, what I understand is when I use
composition, where I may use objects of other classes to create
my object but the client may not even know that it
is made up of other objects. It's implementation is kind of hidden
from the client who using this composite class.
But in case of Aggregation, my object though it uses other objects,
it is known to the client and also client has acess to the interface of
the object which is used to create my object.
Did I get it right?
I want to give points to Nietod.
Do I have to first reject SampsonC's answer?
Thanks Nietod for your explanation.
Actually if I look at the examples where composition or
Aggregation is used, they might look similar to me sometimes
but from your explanation, what I understand is when I use
composition, where I may use objects of other classes to create
my object but the client may not even know that it
is made up of other objects. It's implementation is kind of hidden
from the client who using this composite class.
But in case of Aggregation, my object though it uses other objects,
it is known to the client and also client has acess to the interface of
the object which is used to create my object.
Did I get it right?
I want to give points to Nietod.
Do I have to first reject SampsonC's answer?
>> Did I get it right?
Yes, but like I did in my explanation, you really are talking about the two extremes. there are all sorts of cases in between these extremes that are harder to classify.
For example, it is possible to have cases where a composite/aggregate exposes the fact that it contains some specific data members. For example those member may be made public, or there may be a member procedure that returns a non-constant reference to the data member (a reference would allow the caller to change the data member). Would this object still be a composite? The object being used is a data member, so it suggests the object is a composite, but the client can "work with" this contained object, which suggests the object is an aggregate. On the other hand you can have aggregate/composites that have pointers to object, but don't allow the client to work with those objects. Are they composites or aggregates?
At the extremes it is clear, but in between its a matter of opion.
>> Do I have to first reject SampsonC's answer?
Yes.
Yes, but like I did in my explanation, you really are talking about the two extremes. there are all sorts of cases in between these extremes that are harder to classify.
For example, it is possible to have cases where a composite/aggregate exposes the fact that it contains some specific data members. For example those member may be made public, or there may be a member procedure that returns a non-constant reference to the data member (a reference would allow the caller to change the data member). Would this object still be a composite? The object being used is a data member, so it suggests the object is a composite, but the client can "work with" this contained object, which suggests the object is an aggregate. On the other hand you can have aggregate/composites that have pointers to object, but don't allow the client to work with those objects. Are they composites or aggregates?
At the extremes it is clear, but in between its a matter of opion.
>> Do I have to first reject SampsonC's answer?
Yes.
ASKER
Thank you SampsonC for trying to help me.
But Nietod's explanation was more clear and helped me
in understanding what I wanted.
But Nietod's explanation was more clear and helped me
in understanding what I wanted.
ASKER
Thank you SampsonC for trying to help me.
But Nietod's explanation was more clear and helped me
in understanding what I wanted.
But Nietod's explanation was more clear and helped me
in understanding what I wanted.
hello nietod,
u have given a nice explanation,i want to know more about this but if possible in Java which is what I understand most.
I have seen that the C++ community responds more than Java community and there r lotsa good discussions here,all the newbies have shifted their interest to Java ,mostly those who r interested stay here.
If you agree then I will post a question for you to answer,and am waiting for you ,if you don't pls tell.
Thanks
u have given a nice explanation,i want to know more about this but if possible in Java which is what I understand most.
I have seen that the C++ community responds more than Java community and there r lotsa good discussions here,all the newbies have shifted their interest to Java ,mostly those who r interested stay here.
If you agree then I will post a question for you to answer,and am waiting for you ,if you don't pls tell.
Thanks
I don't know java. But the principles I described are general OOP principles that can be applied to any OOP languange. The only difference between languages is the syntax and language features you use to apply the principles. If you know java, that should not be hard.
Ok ,
what i meant was that I have to do some design work from scratch so i wanted to knwo of a good introduction to OOP.doing it in Rational Enterprise edition.
i presume u r ready to answer?posted it
https://www.experts-exchange.com/jsp/qShow.jsp?ta=cplusprog&qid=10243045
what i meant was that I have to do some design work from scratch so i wanted to knwo of a good introduction to OOP.doing it in Rational Enterprise edition.
i presume u r ready to answer?posted it
https://www.experts-exchange.com/jsp/qShow.jsp?ta=cplusprog&qid=10243045
Got here in the end mb...
Rather a confusing net of questions you have posted but as no one has mentioned it yet also have a look at:
Applying UMl and Patterns : An Introduction to Object-Oriented Analysis and Design
(Craig Larman)
as well. Good practical intro.
Rather a confusing net of questions you have posted but as no one has mentioned it yet also have a look at:
Applying UMl and Patterns : An Introduction to Object-Oriented Analysis and Design
(Craig Larman)
as well. Good practical intro.
As nietod points out there are complications to this but here are some examples which can help clear the muddy waters...
These are java examples in case you C++ boys are wondering about the strange looking code...
An example of aggregation could be considered as a library class which contains a variable number of bokk objects.
Composition is a little more complex but take for example, a class window which could inherit from a class called Rectangle and another class called UserInterfaceObject. This would be multiple inheritance implying that a Window IS a Rectangle and is ALSO a UserInterfaceObject.
However, what if you want to make a round window? You cannot have a Window that is both round and a rectangle so it is no longer correct to say that your Window inherits from Rectangle if it is round. You will have to change your class heirarchy so that it makes sense.
If you use delegation you avoid this by keeping a reference to a Rectangle object and also to a UserInterfaceObject. You then delegate Rectangle specific functions to the rectangle and UserInterfaceObject specific functions to the UserInterfaceObject.
This is called Object composition. In general it is ALWAYS possible to replace inheritance with object composition if you wish to.
In the above example it would work something like this:
public class Window {
//set up window...
boolean circularWindow = false;
boolean rectangularWindow = false;
Circle circle;
Rectabgle rect;
public void setWindowType (String windowType){
if (windowType.equals("circle
circularWindow = true;
rectangularWindow = false;
circle = new Circle(myradius);
} else {
circularWindow = false;
rectangularWindow = true;
rect = new Rectangle(mywidth, myheight);
}
}
public int windowArea {
int area = 0;
if (circularWindow) {
area = rectangle.getArea();
} else if (rectangularWindow) {
area = circle.getArea();
}
return area;
}
}
This is a very simple example I have just written and there are better ways of doing this, but it shows how you can still inherit functionality without commiting your class heirarchy. In the above code you can even change your window from being a rectangle into a circle AFTER you have created it.
The counter side is that your code is a little more complex as you can see.
These are java examples in case you C++ boys are wondering about the strange looking code...
An example of aggregation could be considered as a library class which contains a variable number of bokk objects.
Composition is a little more complex but take for example, a class window which could inherit from a class called Rectangle and another class called UserInterfaceObject. This would be multiple inheritance implying that a Window IS a Rectangle and is ALSO a UserInterfaceObject.
However, what if you want to make a round window? You cannot have a Window that is both round and a rectangle so it is no longer correct to say that your Window inherits from Rectangle if it is round. You will have to change your class heirarchy so that it makes sense.
If you use delegation you avoid this by keeping a reference to a Rectangle object and also to a UserInterfaceObject. You then delegate Rectangle specific functions to the rectangle and UserInterfaceObject specific functions to the UserInterfaceObject.
This is called Object composition. In general it is ALWAYS possible to replace inheritance with object composition if you wish to.
In the above example it would work something like this:
public class Window {
//set up window...
boolean circularWindow = false;
boolean rectangularWindow = false;
Circle circle;
Rectabgle rect;
public void setWindowType (String windowType){
if (windowType.equals("circle
circularWindow = true;
rectangularWindow = false;
circle = new Circle(myradius);
} else {
circularWindow = false;
rectangularWindow = true;
rect = new Rectangle(mywidth, myheight);
}
}
public int windowArea {
int area = 0;
if (circularWindow) {
area = rectangle.getArea();
} else if (rectangularWindow) {
area = circle.getArea();
}
return area;
}
}
This is a very simple example I have just written and there are better ways of doing this, but it shows how you can still inherit functionality without commiting your class heirarchy. In the above code you can even change your window from being a rectangle into a circle AFTER you have created it.
The counter side is that your code is a little more complex as you can see.
Hey Jod,
Thanks man ,very much .I will sit down later and then read this question again and fix the concepts in mind.
I was reading the Scott Meyer's 2nd volume and his explanation of vtbl's & vptr was superb.
If u do have it then re read it.What the hell man ,that is one of the reasons Java is slowed down.Lots of virtual functions everywhere.I have certain questions regarding this and other things but will ask them later on after I have spent some more time in this area.
nietod,
For your Information I plan to implement the Singleton Pattern suggested by Scott in our GUI Screens as we want only 1 screen instance of a particular screen to come up at a time.
I believe that this treatment is better than that given in Thinking in Java by Bruce Eckel.
Jod,
Read these thumbnails
http://www.cse.unsw.edu.au/~timm/pub/subjects/oois96/rules.html
by Arthur Riel
and this too by Bill Venners
http://www.artima.com/
Now I wonder why doesnt somebody write something like Scott has done for Java?
Effective Java
More Effective Java
Jod ,r u game for that? I will be ur first willing book buyer.
:-)
Thanks man ,very much .I will sit down later and then read this question again and fix the concepts in mind.
I was reading the Scott Meyer's 2nd volume and his explanation of vtbl's & vptr was superb.
If u do have it then re read it.What the hell man ,that is one of the reasons Java is slowed down.Lots of virtual functions everywhere.I have certain questions regarding this and other things but will ask them later on after I have spent some more time in this area.
nietod,
For your Information I plan to implement the Singleton Pattern suggested by Scott in our GUI Screens as we want only 1 screen instance of a particular screen to come up at a time.
I believe that this treatment is better than that given in Thinking in Java by Bruce Eckel.
Jod,
Read these thumbnails
http://www.cse.unsw.edu.au/~timm/pub/subjects/oois96/rules.html
by Arthur Riel
and this too by Bill Venners
http://www.artima.com/
Now I wonder why doesnt somebody write something like Scott has done for Java?
Effective Java
More Effective Java
Jod ,r u game for that? I will be ur first willing book buyer.
:-)
>> ...vtbl's & vptr...
Makes me shudder - I'm buried back in C and C++ code at the moment and can't wait to get back to Java again. I had forgotten quite how messy C can be...
Along similar lines, have you looked at how COM works by the way? You might find that interesting.
The only trouble with thinking in Java is that it just doesn't go deep enough into some subjects and patterns is one area along with swing as well really. But it is an intro book as opposed to an advanced book so it can be forgiven.
I'm gonna write a book one day, but I was rather hoping it would have nothing to do with computers...:-)
Makes me shudder - I'm buried back in C and C++ code at the moment and can't wait to get back to Java again. I had forgotten quite how messy C can be...
Along similar lines, have you looked at how COM works by the way? You might find that interesting.
The only trouble with thinking in Java is that it just doesn't go deep enough into some subjects and patterns is one area along with swing as well really. But it is an intro book as opposed to an advanced book so it can be forgiven.
I'm gonna write a book one day, but I was rather hoping it would have nothing to do with computers...:-)
COM ?what is that? is there such a thing as that?
I am a CORBA fan all along
Well then on what subject r u writing abt?Do tell
nietod,
I have implemented that,many thanks.
Also the explanation of Lazy evaluation is superb ,many people mention this but I cant understand this unless its shown in code.
I am a CORBA fan all along
Well then on what subject r u writing abt?Do tell
nietod,
I have implemented that,many thanks.
Also the explanation of Lazy evaluation is superb ,many people mention this but I cant understand this unless its shown in code.
If you want to go to pointer heaven (or hell depending on your point of view) then you can look at how COM works, using pointers to tables of virtual confusion something like this:
A COM object is a kind of object that originated with Microsoft's Component Object Model (COM). COM objects completely hide their data and expose their methods through a construct called an interface. A COM interface is a grouping of related methods that is uniquely identified for all programs and all time (by an Interface ID). Interfaces are used to encapsulate COM object feature sets. The most fundamental feature set in COM gives COM objects their nature as COM objects. The IUnknown interface exposes this feature set in several methods (AddRef, Release, and QueryInterface) that determine the common behavior governing all COM object lifetimes and how interfaces on COM objects are properly acquired.
Outside users of a COM object can only use the object by acquiring one of its interfaces. This acquisition of an interface is achieved by obtaining a pointer to the COM object's implementation of the interface. COM objects "know" about the interfaces they expose to clients and can provide pointer references to the interface implementations. Likewise, COM objects know about how many interface references they have handed out to clients and can thus control their own lifetime. When no references remain, the object normally removes itself from memory and ceases to exist.
The separation between service user and implementation is done by indirect function calls. A COM interface is nothing more than a named table of function pointers (methods), each of which has documented behavior. The behavior is documented in terms of the interface function's parameters and a model of the state within the object instance. The description of the model within the instance will say no more than is required to make the behavior of the other methods in the interface understandable. The table of functions is referred to as a vtable. Here is an example interface expressed in C:
typedef struct
{
struct IFooVtbl *lpVtbl;
} IFoo;
typedef struct
{
// IUnknown methods
HRESULT (*QueryInterface) (IFoo *, REFIID, void **);
ULONG (*AddRef) (IFoo *);
ULONG (*Release) (IFoo *);
// IFoo methods
HRESULT (*SetValue) (IFoo *, int);
HRESULT (*GetValue) (IFoo *,int *);
} IFooVtbl;
A COM object is a kind of object that originated with Microsoft's Component Object Model (COM). COM objects completely hide their data and expose their methods through a construct called an interface. A COM interface is a grouping of related methods that is uniquely identified for all programs and all time (by an Interface ID). Interfaces are used to encapsulate COM object feature sets. The most fundamental feature set in COM gives COM objects their nature as COM objects. The IUnknown interface exposes this feature set in several methods (AddRef, Release, and QueryInterface) that determine the common behavior governing all COM object lifetimes and how interfaces on COM objects are properly acquired.
Outside users of a COM object can only use the object by acquiring one of its interfaces. This acquisition of an interface is achieved by obtaining a pointer to the COM object's implementation of the interface. COM objects "know" about the interfaces they expose to clients and can provide pointer references to the interface implementations. Likewise, COM objects know about how many interface references they have handed out to clients and can thus control their own lifetime. When no references remain, the object normally removes itself from memory and ceases to exist.
The separation between service user and implementation is done by indirect function calls. A COM interface is nothing more than a named table of function pointers (methods), each of which has documented behavior. The behavior is documented in terms of the interface function's parameters and a model of the state within the object instance. The description of the model within the instance will say no more than is required to make the behavior of the other methods in the interface understandable. The table of functions is referred to as a vtable. Here is an example interface expressed in C:
typedef struct
{
struct IFooVtbl *lpVtbl;
} IFoo;
typedef struct
{
// IUnknown methods
HRESULT (*QueryInterface) (IFoo *, REFIID, void **);
ULONG (*AddRef) (IFoo *);
ULONG (*Release) (IFoo *);
// IFoo methods
HRESULT (*SetValue) (IFoo *, int);
HRESULT (*GetValue) (IFoo *,int *);
} IFooVtbl;
Jod,
some of my colleagues r into this ,and I am going to be shifted to CORBA (Solaris sparc ,C++)after 3 months if I stay at this place.I wanna stay in Java so...
So if u got any nice URL's do tell.they can be useful for them
some of my colleagues r into this ,and I am going to be shifted to CORBA (Solaris sparc ,C++)after 3 months if I stay at this place.I wanna stay in Java so...
So if u got any nice URL's do tell.they can be useful for them
CORBA is not a bad way to go - leads to very large corporate style projects. Not my thing at the moment.
COM is not as good as CORBA. That's a bit of a sweeping statement but it is my opinion after having seen both at work.
CORBA and Java could well be the future for a lot of systems.
(Funny - doesn't C++ code look nasty and messy after using Java for a while...)
COM is not as good as CORBA. That's a bit of a sweeping statement but it is my opinion after having seen both at work.
CORBA and Java could well be the future for a lot of systems.
(Funny - doesn't C++ code look nasty and messy after using Java for a while...)
No they are not synonyms, but they are very very similar.