Aggregation and Composition
Aggregation and composition are two types of relationships in object-oriented programming (OOP).
Both represent ownership associations between objects but differ in levels of dependency and lifecycle management.
🤝 Aggregation
Aggregation is a type of relationship between a main object (aggregate) and a part object (component), based on the idea that the part object is not dependent on the main object. In other words, the aggregate has a weak coupling with the component.
In Detail
- Weak Dependency: The component can exist independently of the aggregate. The aggregate has no control over the component's lifecycle.
- Lifecycle: Components and aggregates can be created and destroyed at different times without dependency on one another.
- Example: Consider the objects “Library” and “Book.” A library has books, but books do not depend on the library to exist. Therefore, books are aggregated components of the library.
👏 Composition
In composition, the part object (component) is created by the main object (aggregate) and not received from external sources, indicating strong coupling between the objects.
In Detail
- Strong Dependency: The component is created by the aggregate, either through a constructor or a specific method.
- Lifecycle: The component's lifecycle is directly linked to the aggregate's lifecycle; in other words, the component's existence depends on the aggregate.
- Example: Consider the objects “House” and “Room.” A house has rooms, but unlike the previous example, a room can only exist if the house exists. This defines a composition relationship.
Moral of the Story
Conceptually, aggregation and composition define the semantics of object relationships, helping us understand which objects depend on others for existence.
Note that this understanding is conceptual; in practice, implementing these two types of relationships has few differences.
In other words, in code, aggregation and composition can be written in various ways because we deal with broader concepts than just object relationships. In reality, we must also consider performance, reusability, and class decoupling.
Thank you very much for reading! 👋