3 Important Concepts: - Association, Aggregation and Composition

Introduction

In this article, we will try to understand 3 important concepts association, aggregation, and composition.

We will also try to understand what kind of scenarios we need them. These 3 concepts have confused lots of developers and in this article, I will attempt to present the concepts in a simplified manner with some real-world examples.

Extracting real-world relationships from the requirement

The whole point of OOP is that your code replicates the real-world object, thus making your code readable and maintainable. The time we say real world, the real world has relationships. Let's consider the simple requirements listed below.

1. The manager is an employee of XYZ Limited Corporation.
2. The manager uses a swipe card to enter XYZ premises.
3. The manager has workers who work under him.
4. The manager has the responsibility of ensuring that the project is successful.
5. The manager's salary will be judged based on project success.

If you flesh out the above 5-point requirement we can easily visualize 4 relationships.

• Inheritance
• Aggregation
• Association
• Composition

Let's understand them one by one.

Requirement 1 (The IS-A relationship)

If you see the first requirement (Manager is an employee of XYZ limited corporation) it's a parent-child relationship or inheritance relationship. The sentence above specifies that Manager is a type of employee, in other words, we will have two classes one the parent class "Employee" and the other a child class "Manager" which will inherit from the "Employee" class.

Note. The scope of this article is only limited to aggregation, association, and composition. So we will not discuss inheritance in this article as it's pretty straight forward and I am sure you can get1000 of articles on the net which will help you in understanding the same.

Requirement 2 (The Using relationship: - Association)

Requirement 2 is interesting (the Manager uses a swipe card to enter XYZ premises). In this requirement, the manager object and swipe card object use each other but they have their own object lifetime. In other words, they can exist without each other. The most important point in this relationship is that there is no single owner.

The above diagram shows how the "SwipeCard" class uses the "Manager" class and the "Manager" class uses the "SwipeCard" class. You can also see how we can create the object of the "Manager" class and "SwipeCard" independently and they can have their object lifetime.

This relationship is called the "Association" relationship.

Requirement 3 (the using relationship with parent Aggregation)

The third requirement from our list (The manager has workers who work under him) denotes the same type of relationship as an association but with the difference that one of them is an owner. So as per the requirement, the "Manager" object will own the "Workers" object.

The child "Worker" objects can not belong to any other objects. For instance, the "Worker" object cannot belong to the "SwipeCard" object.

But....the "Worker" object can have its lifetime which is completely disconnected from the "Manager" object. Looking from a different perspective it means that if the "Manager" object is deleted the "Worker" object does not die.

This relationship is termed the "Aggregation" relationship.

Requirements 4 and 5 (The Death relationship: - Composition)

The last two requirements are logically one. If you read closely both the requirements are as follows.

1. The manager has the responsibility of ensuring that the project is successful.
2. The manager's salary will be judged based on project success.

Below is the conclusion from analyzing the above requirements:-

1. The manager and the project objects are dependent on each other.
2. The lifetimes of both objects are the same. In other words, the project will not be successful if the manager is not good and the manager will not get good increments if the project has issues.

Below is what the class formation will look like. You can also see when I go to create the project object it needs the manager object.

This relationship is termed the composition relationship. In this relationship, both objects are heavily dependent on each other. In other words, if goes for garbage collection the other also has to be collected or put from a different perspective the lifetime of the objects are same. That's why I have put in the heading "Death" relationship.

Putting things together

Below is a visual representation of how the relationships have emerged from the requirements.

The source code

You can also download the source from ...

Summarizing

To avoid confusion henceforth in these 3 terms I have put forward a table below which will help us compare them from 3 angles owner, lifetime, and child object.

	Association	Aggregation	Composition
Owner	No Owner	Single owner	Single Owner
Lifetime	Have their own lifetime.	Have their own lifetime.	Owners lifetime
Child object	No Child objects all are independent	Child objects belong to a single parent.	Child objects belong to a single parent.

Video on Association, Aggregation, and Composition

I have also added a video on Association, Aggregation, and Composition in case you do not want to read this long article.

Just a note I have recorded around 500 videos, do have once a look at my videos on .NET, OOP, SQL Server, WCF, Silverlight, LINQ, VSTS, SharePoint, Design patterns, UML, and a lot more.