This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
What is the difference between Asscoiation, Composition and Aggregration.
I had gone through previos posts but was not able to clear distinguish between these three.
Can I have an example of all the three for a scenario
AggregationAndComposition uml 17 May 2003 Few things in the UML cause more consternation than aggregation and composition, in particular how they vary from regular association. The full story is muddied by history. In the pre-UML methods there was a common notion of defining some form of part-whole relationships. The trouble was that each method defined different semantics for these relationships (although to be fair, some of these were pretty semantics free). So when the time came to standardize, lots of people wanted part-whole relationships, but they couldn't agree on what they meant. So the UML definers introduced two relationships. aggregation (white diamond) has no semantics beyond that of a regular association. It is, as Jim Rumbaugh puts it, a modeling placebo. People can, and do, use it - but there are no standard meanings for it. So if you see it, you should inquire as to what the author means by it. I would advise not using it yourself without some form of explanation. composition (black diamond) does carry semantics. The most particular is that an object can only be the part of one composition relationship. So even if both windows and panels can hold menu-bars, any instance of menu-bar must be only held by one whole. This isn't a constraint that you can easily express with the regular multiplicity markers.
Originally posted by aakash bhatt: What is the difference between Asscoiation, Composition and Aggregration.
As example: A person needs to have a heart, a liver, a head. This you would model as composition. A person may have a car, a house, a sun-workstation. This would be an aggregation. In programming, the situation is normally not that clear (and in real live, you always find examples, which contradict your theory - people with two heads, synthetic heart and no liver at all . If my classes, when X has an Y, then mostly because it needs to have it. I guess you use association, if the attribut has it's own livecycle, and is only referenced by the class (the class may change this association and exist without this attribut).
For a slightly different view look at http://ootips.org/uml-hasa.html (notice that in a garbage collected language like Java, lifetime responsibility is rather uninteresting). In the end, semantics of aggregation and composition are weakly defined and - more importantly - not well understood by most people. So if you decide to use them, the most important part is to decide on the semantics *you* will use and making sure that they are understood by your audience.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
In Lasse Koskela's example, I think aggregation and composition code are misplaced. It should be: Aggregation:
Am I right? Comert
Originally posted by Lasse Koskela: Here are a couple of quick examples. Guys, correct me if I forgot to think while typing Association(s):
Joined: Jan 23, 2002
Originally posted by Comert Sagiroglu: In Lasse Koskela's example, I think aggregation and composition code are misplaced.
You're absolutely correct. Thanks for correcting me.
Joined: Jul 11, 2001
Aside from the comments, any of the above code examples could be either composition, aggregation or simply association. For example, in composition the whole is allowed to accept the responsibility for the part from - or hand it to - another object.
1) Association: any relation between two objects/classes. Composition and Aggregation are types of associations.
2) Composition: the object only exists, or only makes sense inside ther other, as a part of the other. Ex: People - heart. You don't creat a heart and than passes it to a person.
3) Aggregation: the object exists outside the other, is created outside, so it is passed as an argument (for example) to the construtor. Ex: People - car. The car is create in a diferent context and than becomes a person property.
I think Fowler's (among many others) view on this (see link above) is dead-on:
Just don't use aggregation! (my words, not his)
Composition, on the other hand, does imply certain semantics. From link given earlier in this thread:
composition (black diamond) does carry semantics. The most particular is that an object can only be the part of one composition relationship.
I was recently involved in the creation of Sun's new Java Associate exam. There's some basic UML on the exam and we chose to limit the types of relationships to simple associations and composition in order to avoid all the ambiguity.
Co-Author of <a href="http://www.oreilly.com/catalog/jswing2" target="_blank" rel="nofollow">Java Swing</a><br />Co-Creator of <a href="http://www.sun.com/training/catalog/courses/CX-310-055.xml" target="_blank" rel="nofollow">SCJP 5.0</a> and <a href="http://www.sun.com/training/certification/java/associate_beta.xml" target="_blank" rel="nofollow">SCJA</a> exams
Originally posted by Maki Jav:But what is "clearly" an association then?
When one class makes a reference to another, there's an association between the two. If only one refers to the other but not vice versa, the association has a direction. [ September 27, 2007: Message edited by: Allan Halme ]
<i>The lyf so short, the craft so long to lerne.</i> --Geoffrey Chaucer (c. 1343-1400)
The Conclusion which i can derive from this Thread is Aggregation and Composition are two types of association. Assocaiton on the broader sense means reference of two objects.
If i refer to the examples posted by Lasse and Comert. But according to my later theory the first one is association and second one is aggregation.Where in composition comes when i can destroy the object. Which is conditionlally possible.
[ December 13, 2007: Message edited by: saurav sarkar ] [ December 13, 2007: Message edited by: saurav sarkar ]
Be Objectively Oriented.Explore the power of OOPs.
My Blog, Eclipse EMF Query committer.
Lasse's example originally reversed Aggregation and Composition and Combert's example was already discussed in your earlier topic.
In composition the whole is responsible for managing the parts (not just simply using them) and the part can only belong to one whole. In Java composition is harder to spot because memory is the most common resource. However in the JVM memory is a managed resource so no object ever manages its own memory or the memory of its parts. However once you deal with unmanaged resources composition is easier to spot. Once you are dealing with unmanaged resources you need to release them in a deterministic fashion - releasing them in the finalize method isn't reliable. So code tends to look like this:
The DriverManager assembles the WHOLE (Connection) from its PARTS (unmanaged resources). Once successfully assembled the Connection is a working WHOLE. But once you are done playing, it is time to put away your toys. So in order to return those unmanaged (scarce) resources to the operating system at the earliest possible point you need to call conn.close(). The Connection (WHOLE) releases its unmanaged resources (PARTS) - the WHOLE manages the lifecycle of the PARTS. At this point the connection is only an empty shell waiting for the next garbage collection sweep (providing the nothing is holding a reference to it). This behavior is a good indication that the unmanaged resources (PARTS) are in a composition relationship with the Connection (WHOLE).
Now the WebServer (WHOLE) example which creates its own (new) HttpListener and RequestProcessor (PARTS) is an example of composition because it is clear that no one else has a reference to its parts. The web server creates its own parts and stores private references to them and never hands these references out to anyone. Therefore the HttpListener and RequestProcessor instances will be garbage collected together with the WebServer instance. In effect the lifecycle of the WHOLE implicitly manages the lifecycle of its PARTS.
The other WebServer example can still be an example of composition - however that depends on what is going on outside of the WebServer:
The WebServer instance is still the only one that has a reference to the HttpListener and RequestProcessor. The HttpListener and RequestProcessor will be garbage collected together with the WebServer instance. So this still is Composition.
Here the listener and processor are shared between two WebServer instances. Definitely NOT composition - this is aggregation.
In composition a PART does not survive the release/destruction of its (current) WHOLE. In rare cases it is possible for a PART to be transferred from one WHOLE to another as long as only one WHOLE "owns" the PART at any one time. So it is possible for a PART to exist past the lifetime of a WHOLE that it may have been associated with in the past. With most examples of composition however, the PART stays for its entire lifetime with the same WHOLE.
Originally posted by aakash bhatt:
What is the difference between Asscoiation, Composition and Aggregration.
A person needs to have a heart, a liver, a head.
This you would model as composition.
A person may have a car, a house, a sun-workstation.
This would be an aggregation.
In programming, the situation is normally not that clear (and in real live, you always find examples, which contradict your theory - people with two heads, synthetic heart and no liver at all .
If my classes, when X has an Y, then mostly because it needs to have it.
I guess you use association, if the attribut has it's own livecycle, and is only referenced by the class (the class may change this association and exist without this attribut).
..Not quite, In my understanding the analogy of aggregation is parts that make up a whole. In your example of person - car- house -sun workstation, the missing factor is the lifecycle relationship. In this case is the person responsible for the lifecycle of the car, thr house, or the workstation? If you remove the person, do these object become obsolete? I believe not, in this case it is a stronger candidate for association not aggregation. For me aggregation conforms more to the well used example of a PC, which is made up of a monitor, tower Screen, mouse etc. Further the initial comprehension of ' Has - a' is association. I think programmatically, its hard to differentiate between compostion and association.
be a well encapsulated person, don't expose your privates, unless you public void getWife()!