Difference between Association, Aggregation, and Composition
Association is a*has-a*relationship between two classes where there is no particular ownership in place. It is just the connectivity between the two classes. When you define a variable of one class in another class, you enable first toassociatefunctions and properties of the second class. Then again both AggregationandCompositionare types ofAssociation.
Aggregation is aweaktype of Association with partialownership. For an Aggregation relationship, we use the term*uses*to imply aweak*has-a*relationship. This is weak compared to Composition. Then again, weak meaning the linked components of the aggregator may survive the aggregations life-cycle without the existence of their parent objects. For example, a school department*uses*teachers. Any teacher may belong to more than one department. And so, if a department ceases to exist, the teacher will still exist.
On the other hand,Composition is a strong type of Association with full ownership. This is strong compared to the weak Aggregation. For a Composition relationship, we use the term*owns*to imply a strong*has-a*relationship. For example, a department*owns*courses, which means that the any course's life-cycle depends on the department's life-cycle. Hence, if a department ceases to exist, the underlying courses will cease to exist as well.
Whenever there is no ownership in place, we regard such a relationship as just an Associationand we simply use the*has-a*term, or sometimes theverbdescribing the relationship. For example, a teacher*has-a*or*teaches*a student. There is no ownership between the teacher and the student, and each has their own life-cycle.
In the example given above, I can say thatUniversityaggregateChancellororUniversityhas an (*has-a*)Chancellor. But even without aChancelloraUniversitycan exists. But theFaculties_cannot exist without theUniversity, the life time of aFaculty(or Faculties) attached with the life time of theUniversity. IfUniversityis disposed the_Faculties_will not exist. In that case we called thatUniversityis composed of_Faculties. So that composition can be recognized as a special type (strong kind) of an aggregation.
Same way, as another example, you can say that, there is a composite relationship in-between aKeyValuePairCollectionand aKeyValuePair. As it was with the Faculty and the University, the two mutually depend on each other.
.NET and Java uses the Composite relation to define their Collections. I see Composition is being used in many other ways too. However the more important factor, that most people forget is the life time factor. The life time of the two classes that has bond with a composite relation mutually depend on each other. If you take the .NET Collection to understand this, there you have the Collection element define inside (it is an inner part, hence called it is composed of) the Collection, farcing the Element to get disposed with the Collection. If not, as an example, if you define the Collection and it’s Element to be independent, then the relationship would be more of a type Aggregation, than a Composition. So the point is, if you want to bind two classes with Composite relation, more accurate way is to have a one define inside the other class (making it a protected or private class). This way you are allowing the outer class to fulfill its purpose, while tying the lifetime of the inner class with the outer class.
So in summary, we can say that aggregation is a special kind of an association and composition is a special kind of an aggregation. (Association->Aggregation->Composition)
