Introduction

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

We will also try to understand in what kind of scenarios we need them. These three concepts have really confused a lot of developers and in this article, my attempt would
be to present the concepts in a simplified manner with some real world examples.

Extracting real world relationships from a requirement

The whole point of OOP is that your code replicates real world objects, thus making your code readable and maintainable.
When we say real world, the real world has relationships. Let’s consider the simple requirement listed below:

Manager is an employee of XYZ limited corporation.

Manager uses a swipe card to enter XYZ premises.

Manager has workers who work under him.

Manager has the responsibility of ensuring that the project is successful.

Manager's salary will be judged based on project success.

If you flesh out the above five point requirement, we can easily visualize four relationships:-

Inheritance

Aggregation

Association

Composition

Let’s understand them one by one.

Requirement 1: The IS A relationship

If you look at 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: parent class Employee, and 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. We will not discuss inheritance in this article
as it is pretty straightforward and I am sure you can get 1000s of articles on the net which will help you in understanding it.

Requirement 2: The Using relationship: Association

Requirement 2 is an interesting requirement (Manager uses a swipe card to enter XYZ premises). In this requirement, the manager object and the swipe card object
use each other but they have their own object life time. 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 objects of the Manager class and SwipeCard class independently and they can have their own object life time.

This relationship is called the “Association” relationship.

Requirement 3: The Using relationship with Parent: Aggregation

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

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

But… the Worker object can have its own life time 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 as an “Aggregation” relationship.

Requirements 4 and 5: The Death relationship: Composition

The last two requirements are actually logically one. If you read closely, the requirements are as follows:

Manager has the responsibility of ensuring that the project is successful.

Manager's salary will be judged based on project success.

Below is the conclusion from analyzing the above requirements:

Manager and the project objects are dependent on each other.

The lifetimes of both the 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 how the class formation will look like. You can also see that when I go to create the project object, it needs the manager object.

This relationship is termed as the composition relationship. In this relationship, both objects are heavily dependent on each other.
In other words, if one goes for garbage collection the other also has to be garbage collected, or putting from a different perspective, the lifetime of the objects are
the 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.

Comments and Discussions

For aggregation its mentioned that Child objects belong to a single parent (in summary table).
As per my understanding in aggregation the child object can be aggregated by other objects also and hence can have more than one parent. Is my understanding correct?

hey in case of aggregation, how you initialize worker object in class scope. you have to initialize in somewhere method. because as by u did, this behavior matches to composition. if manager obj destroy so worker will also destroy bcoz worker behaves like manager data item. please if i am wrong. correct me through khayamabdulnasir@gmail.com

Thanks for the article.
This is regarding the Composition section of your Article. In composition relationship, "Lifetime of Part depends on the Lifetime of Whole". In your example, "Project" and "Manager" is not developing a part-whole relation. Your are passing the the "Manager" object in "Project"'s constructor. You are creating the "Manager" object outside the "Project". So, your "Manager" can still survive even "Project" is destroyed.As far as my concept goes, I agree this is a case of "Aggregation" and also might result to a dependency but not a Composition. Please correct me if I am wrong.

Don't think Manager as Physical Entity..consider it as a logical entity..An Employee is Manager only when that Employee is assigned a Project(then employee becomes Manager),and when project is complete(destroyed) then employee's Role as a manager may be revoked.

I spent entire weekend reading all your articles. Gotta say, I loved them. It was time well spent. I spent all my Monday early morning voting, categorizing and bookmarking my favourite ones. Loved the content, became fan of presentation style.

Every now and then say, "What the Elephant." "What the Elephant" gives you freedom. Freedom brings opportunity. Opportunity makes your future.

That's definitely more simplified. I have not see the Wheel class. But the wheel class should also refer the car object so that there is tight bonding or else i can attach the wheel to trucks also which probably is more of aggregation.

Yep, thats exactly the difference (Wheels and engine in my example don't reference the car, nethertheless I say this is composition). I wrote this with C++ in mind, so engine and wheels cannot extend their lifecycle beyond that of the car. They also cannot be moved to another car, only copied.

Hi Shivprasad,
It is a nice article, just wanted to share my views on it.
Well, it is not 100% true that inheritance is a parent child relationship. In your example you mentioned "Employee" as parent of "Manager" class, this is partially true.
Inheritance can also not identified with IS-A relationship also, sometimes you have contradictions here. For example: square is a rectangle, yes true if you stretch any of the dimensions square becomes rectangle, that means square IS-A rectangle....and the reverse also true.
No, This is not true neither square is a rectangle nor rectangle is a square. They both are specialized form of shape. Hence, Square is a shape or more precisely square is a specialized form of shape. Rectangle is a specialized form of shape. So in my view - Inheritance is from specialization from generalization. I would prefer to call "Manager" is an specialized from of "Employee" and it is inheritance.

My 3 for the effort you have put to format it in the CP style. It is never fun for me at least to format articles for this site - I struggled with the editor.
I would love to give 4, if this is augmented by UML diagrams.

There are many formatting issues, but I could get the essence.
The tags quoted include all the spectrum: beginer - advanced (really this is advanced !!!)
I am suprised that an author with above 100 articles in CP could let these slip away

Quote:

The whole point of OOP is that your code replicates the real world object,

So can't I write generic programming (where I don't have exact object replicates) in OOPs

Quote:

inheritance in this article as its pretty straight forward and I am sure you can get 1000 of articles on the net which will help you in understanding the same.

I typed 'Association vs Aggregation vs compostion' in google and got many more

And it would be nice if there are some supporting UML diagrams as in REAL we will be using them to mention these relationships

Yeah why not then thats functional programming because it does not have classes and object. Did i write something wrong.

Lakamraju Raghuram wrote:

I typed 'Association vs Aggregation vs compostion' in google and got many more

Yeah relatively inheritance is higher in number as the relationship thing is straight forward. Wanted to spend more time discussing association relationship more because of its different thin varities.

Lakamraju Raghuram wrote:

And it would be nice if there are some supporting UML diagrams as in REAL we will be using them to mention these relationships

I did thought about this but then ended up with code images so that people who are juniors can also understand it better. I find the visual code more appealing than UML so that people who do not know UML can grasp it.

Lakamraju Raghuram wrote:

really this is advanced !!!

Its relative. Take a quick discussion about this topic with your developer freinds you will get to know how many of them know these concepts.