What is the difference between aggregation, composition and dependency?
Asked
Active
Viewed 2.9e+01k times
274
-
3reopen: Duplicated link is not exactly the same question (dependency vs association) . Additionally, this question got as much relevance. – Adrian Maire Aug 03 '17 at 16:17
7 Answers
445
Aggregation implies a relationship where the child can exist independently of the parent. Example: Class (parent) and Student (child). Delete the Class and the Students still exist.
Composition implies a relationship where the child cannot exist independent of the parent. Example: House (parent) and Room (child). Rooms don't exist separate to a House.
The above two are forms of containment (hence the parent-child relationships).
Dependency is a weaker form of relationship and in code terms indicates that a class uses another by parameter or return type.
Dependency is a form of association.
-
1Mention the fact that aggregation and composition are specialization of the containment relationship form and it would be perfect. – alphazero Oct 29 '09 at 15:08
-
1:-) Not saying you are right or wrong, but gees these classifications suck. Does Class/Student == Aggregation?... Not according to JavaPapers.com. http://javapapers.com/oops/association-aggregation-composition-abstraction-generalization-realization-dependency/ "A class contains students. A student cannot exist without a class. There exists composition between class and students." – TallPaul Oct 11 '10 at 03:21
-
-
20@tallPaul the paper you mention agrees with my definition of aggregation and composition. It simply uses a different definition for student. It says student cannot exist without class. If that's the case then yes it is composition. If not, it's aggregation. I don't like their premise: students can exist and not be in any classes. – cletus Oct 11 '10 at 04:19
-
However, the concept of a student may not exist. Are you a student if you're not studying anything? – kasperhj Nov 13 '13 at 18:35
-
1you might switch to another class later on :-) also there are lots of students not actually studying... – scravy Feb 25 '15 at 13:25
-
5It's not absolute - it really depends on the business; room can exist without the house if you are designing some CAD software and you tend to drop objects (kitchen, bathroom) on the screen... body parts are not necessarily composition in the body transplantation business. That's why you have to depic what you really want. – Peter Nov 02 '15 at 14:24
-
-
2It all depends on the limitation of your abstraction. Whether you see an entity as a student in class only or outside of class too. – Rahul Rastogi Apr 10 '16 at 13:56
-
147
Aggregation and composition are almost completely identical except that composition is used when the life of the child is completely controlled by the parent.
Aggregation
Car -> Tires
The Tires can be taken off of the Car object and installed on a different one. Also, if the car gets totaled, the tires do not necessarily have to be destroyed.
Composition
Body -> Blood Cell
When the Body object is destroyed the BloodCells get destroyed with it.
Dependency
A relationship between two objects where changing one may affect the other.
nbro
- 15,395
- 32
- 113
- 196
Robert Greiner
- 29,049
- 9
- 65
- 85
-
14Funny, I just read a tutorial where the car-tires example is used to illustrate composition... – mouviciel Nov 04 '09 at 16:18
-
12interesting, I guess it depends on how you look at it. I don't see how destroying the car object also mandates that the tires be destroyed as well. Also, you can take the tires off of a car and put them on a different car. That's the problem with analogies though I suppose. – Robert Greiner Nov 04 '09 at 16:39
-
1Yes, indeed I understood aggregation and composition not with such analogies but with actual code. – mouviciel Nov 04 '09 at 21:23
-
5`interesting, I guess it depends on how you look at it.` I liked the answer, but u know I am confused now. – Kowser Sep 04 '12 at 05:58
-
1This all depends on your model of the domain. Does it make sense for an object to exist without its object or not in your context. – Bjørn Egil Feb 14 '17 at 17:14
-
15Perspective is key here. For instance, Robert does not seem to be aware of the practice of blood donations, or maybe he's a Witness -- so he gets composition. I'd have gone with aggregation. This nicely illustrates that these things are not about absolute truth but about *models*: if in your world/application, tires belong to exactly one car and you destroy them along with the car, use composition; if you switch them between cars, use aggregation. – Raphael Mar 30 '17 at 11:54
-
-
2Too many commenters are hung up on the examples. The sentences describing each appear to be fine. In one design perhaps destroying a car destroys the tires. In someone else's design the tires can be taken off and recycled. That detail is irrelevant. The point is whether or not the underlying thing (child) has the same lifetime as the parent. If the lifetimes are tightly coupled it is a composition. The answer is fine. In a particular program the concept of transferring a blood cell to another body might be unnecessary. It depends on the requirement of the program. – shawn1874 Sep 12 '17 at 19:14
50
Aggregation - separable part to whole. The part has a identity of its own, separate from what it is part of. You could pick that part and move it to another object. (real world examples: wheel -> car, bloodcell -> body)
Composition - non-separable part of the whole. You cannot move the part to another object. more like a property. (real world examples: curve -> road, personality -> person, max_speed -> car, property of object -> object )
Note that a relation that is an aggregate in one design can be a composition in another. Its all about how the relation is to be used in that specific design.
dependency - sensitive to change. (amount of rain -> weather, headposition -> bodyposition)
Note: "Bloodcell" -> Blood" could be "Composition" as Blood Cells can not exist without the entity called Blood. "Blood" -> Body" could be "Aggregation" as Blood can exist without the entity called Body.
7
An object associated with a composition relationship will not exist outside the containing object. Examples are an Appointment and the owner (a Person) or a Calendar; a TestResult and a Patient.
On the other hand, an object that is aggregated by a containing object can exist outside that containing object. Examples are a Door and a House; an Employee and a Department.
A dependency relates to collaboration or delegation, where an object requests services from another object and is therefor dependent on that object. As the client of the service, you want the service interface to remain constant, even if future services are offered.
Mark
- 1,988
- 2
- 24
- 42
5
Aggregation and composition are terms that most people in the OO world have acquired via UML. And UML does a very poor job at defining these terms, as has been demonstrated by, for example, Henderson-Sellers and Barbier ("What is This Thing Called Aggregation?", "Formalization of the Whole-Part Relationship in the Unified Modeling Language"). I don't think that a coherent definition of aggregation and composition can be given if you are interested in being UML-compliant. I suggest you look at the cited works.
Regarding dependency, that's a highly abstract relationship between types (not objects) that can mean almost anything.
CesarGon
- 15,099
- 6
- 57
- 85
1
One object may contain another as a part of its attribute.
- document contains sentences which contain words.
- Computer system has a hard disk, ram, processor etc.
So containment need not be physical. e.g., computer system has a warranty.
Jens Erat
- 37,523
- 16
- 80
- 96
Manish Doshi
- 1,205
- 1
- 9
- 17
0
Containment :- Here to access inner object we have to use outer object. We can reuse the contained object. Aggregation :- Here we can access inner object again and again without using outer object.
Tryst
- 1