Aggregation & Composition in OOPs
- Aggregation and composition in real project define HAS-A relationship.
- Aggregation differs from ordinary composition in that it does not imply ownership.
- In composition, when the owning object is destroyed, so are the contained objects.
- In aggregation, this is not necessarily true.
For example, a university owns various departments (e.g., Physics, chemistry), and each department has a number of professors.
Now due to some reasons, if the university closes, the departments will no longer exist, but the professors in those departments will. Therefore, a University can be seen as a composition of departments, whereas departments have an aggregation of professors.
- Aggregation represents ownership or a whole/part relationship.
- The composition represents an even stronger form of ownership. With composition, we get a coincident lifetime of part with the whole. The composite object has sole responsibility for the disposition of its parts in terms of creation and destruction. In implementation terms, the composite is responsible for memory allocation and de-allocation. An object may be part of only one composite at a time. If the composite is destroyed, it must either destroy all its parts or else give responsibility for them to some other object. A composite object can be designed with the knowledge that no other object will destroy its parts.
- Composition – One class has another class.
- Aggregation – One class is a kind of another class.