inheritance and aggregation
I am looking at uml diagram for composite pattern. I can see a inheritance relationship between the abstract Component class and concrete Composite class which I can understand. The point I don't get is the aggregation relation between the abstract Component class and concrete Composite class (whole). How can this be implemented between two classes
-u
[375 byte] By [
talluryu] at [2007-9-30 4:57:50]

inheritance technique is different from composition. With composition the composite object implements the interface in question, and the compositee (!?) does not have to implement the interface, even if it is actually capable.
I do this a lot. Where you could inherit from an object, instead you wrap it and forward all required calls to it. That object you wrap does not have to implement anything, and often I make sure it does not so I dont confuse the intended usage of it.
Look at the classes in the AWT and Swing packages. In particular look at the Container and the classes that implement it esp. Panel.
It depends on the specifics of the relationship.
For example given Customer, SalesPerson and Order.
A Customer 'owns' a Order. If the Customer does not exist the Order can not exist. And a Customer can have more than one Order. So an implementation of this might be for the Customer class to have a collection (array, ArrayList, whatever) of Orders.
And in particular note that when the Customer is 'deleted' the Orders for that Customer no longer exits.
Now consider that a SalesPerson can be associated to a Customer. But when a SalesPerson is 'deleted' you don't want the Customers to do disappear. They are seperate entities.
So you might have a collection of SalesPersons and a collection of Customers. And a class called LinkSalesPersonToCustomer. This class has a reference to a SalesPerson and a Customer. And the SalesPerson has a collection of these.
Now when the SalesPerson is 'deleted' the collection of links is 'deleted' is well. But that does't get rid of any Customers.
-
There are many ways to do this but typically the following should work as a guideline
- 1 to 1 and first 'owns' the second. Then the second is wholly contained in the first as a direct reference
- 1 to many and first 'owns' the second. Then the second is wholly contained in the first as a direct collection.
- many to many, 1 to x (with no ownership) Then an intermediate link class is used. As a matter of practicality though the link table can contain more than just the links, for instance a ownership flag.
There are many performance implications to the above. For instance a load on demand might be needed. Or the association might be inferred rather than actual (where intermediate classes allow access but do not explicity define the link.)
jshell, that sounds very database centric no? Is there any composition (in the Composite Pattern sense) in those relationships?
> For example given Customer, SalesPerson and Order.
I'm looking at the GoF book and I don't think this example fits the 'Composite Pattern'
The OP is asking about that UML picture in particular.
To the OP - here's a Java example of the UML in the GoF book:
[code]
abstract class Graphic
{
void draw();
void add(Graphic g)
{
throw new UnsupportedOperationException();
}
void remove(Graphic g)
{
throw new UnsupportedOperationException();
}
Graphic getChild(int i)
{
throw new UnsupportedOperationException();
}
}
class Line extends Graphic
{
void draw()
{
// ...
}
}
class Text extends Graphic
{
void draw()
{
// ...
}
}
class Rectangle extends Graphic
{
void draw()
{
// ...
}
}
class Picture extends Graphic
{
List components = new ArrayList();
void draw()
{
// ...
for (Iterator i = components.iterator(); i.hasNext();)
{
// this is overly simplistic
((Graphic) i.next()).draw();
}
// ...
}
void add(Graphic g)
{
components.add(g);
}
void remove(Graphic g)
{
components.remove(g);
}
Graphic getChild(int i)
{
return (Graphic) components.get(i);
}
}
[code]
I think the GOF composite pattern is a little more complicated. They are building up an object by using other objects. But it holds even if you are only encapsulating a single object.
Composite is anytime one object gets its guts/behavior directly from another by encapsulating it, and forwarding its calls.
Perhaps we need clarification on what the OP is seeing/meaning!?
> jshell, that sounds very database centric no? Is> there any composition (in the Composite Pattern sense)> in those relationships?oops!Basically I was answering a question that wasn't asked.
Thanks for all the explanations. Yes I was asking for Gof composite pattern's implementation. And dubwai's implementation is similar to gof book's explanation.
I am ok with association and composition but fuzzy about aggregation. So I guess my real question was about the aggregation between Picture and Graphics and what it means.
OP I am guessing is for original person
> Thanks for all the explanations. Yes I was asking for
> Gof composite pattern's implementation. And dubwai's
> implementation is similar to gof book's explanation.
> I am ok with association and composition but fuzzy
> about aggregation. So I guess my real question was
> about the aggregation between Picture and Graphics and
> what it means.
> OP I am guessing is for original person
Close: Original Poster
class Picture extends Graphic
{
// this is the concrete object that is used to implement the aggregation.
List components = new ArrayList();
thanks. so aggregation stands literally for a collection.u
> thanks. so aggregation stands literally for a
> collection.
> u
Whoa, whoa, whoa, slow down there. Not exactly. A collection is a way to implement an aggregation. An array is another. A map is another. There are many ways to do it. You could have mutliple references to a single Object.
I did not mean java Collection object but more in general. Thanks
Aggregration is basically a compound composite. I think what the GOF describes as the composite pattern is exactly equal to what I would consider aggregration.When I first encountered this methodology it was in microsoft COM, and it was called aggregration.
Here's a couple of sites that might help explain things... http://www.fluffycat.com/java/JavaNotes-GoFComposite.html http://c2.com/cgi-bin/wiki?CompositePattern
pacakage aa.bb;
public class Concatenate{
public String concat(String s1, String s2) {
return s1+s2;
}
}
package aa.bb;
protected class Hello{
private greet(){
Vector vals = getValues(); //get Values
String greeting;
int j = vals.size() - 2;
for (int i=0; i< j; i+2){
greeting = concat ((String)vals(i), (String)vals(j))
}
System.out.println("Hello " + greeting);
}
}
Is this relation aggregation with open diamond at Hello. I have seen lot of theory about these relationships in uml, but don't know exactly which one is aggregation
i dont think that is aggregration because there is no membership. Thats just using another class, but its not absorbing any of that classes behavior as its own. There must be some kind of forwarding i believe.
> i dont think that is aggregration because there is no
> membership. Thats just using another class, but its
> not absorbing any of that classes behavior as its
> own. There must be some kind of forwarding i believe.
The GoF book says regarding the use of the Composite pattern:
<qote>
Use the Composite pattern when
1) you want to represent part-whole hierarchies of objects.
2) you want clients to be able to ignore the difference between compositions of objects and individual objects. Clients will treat all objects in the composite structure uniformly.
</quote>
ad 1) a part-whole hierarchy can be found if you think of an Order and the individual Order Positions to it. The Order Positions then firmly depend on the existance of an Order and will be deleted with it.
ad 2) This describes the usage of this patten in any kind of trees of arbitrary depth. In these trees you usually distinguish between leafs (elements that have no successors) and nodes. As both, Leaf and Node, are derived from the same super class it is easy to take a single element out of this tree and to send a message to it. This message will be understood no matter you are with a Leaf or a Node. An example of this is the Graphics example quoted above.
