In this article we will try to understand 3 important
conceptsassociation, aggregation and composition.
We willalso try to understand in what kind of scenarios do we need them. These
3 concepts have really confused lots of developers and in this article my
attempt would be to present the concepts in a simplified manner with some real
world examples.
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, real world have relationships. Let's consider the simple
requirement listed below:-
- Manager is anemployee 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 5 point requirement we can easily
visualize 4 relationships:-
- Inheritance
- Aggregation
- Association
- Composition
Let's understand them one by one.
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 "Employee" class.
Note: -The scope of this article
is only limited to aggregation, association and composition. So we will not discuss
inheritancein this article as its pretty straight forward and I am sure you can
get1000 of articles on the net which will help you in understanding the same.
The requirement 2 is an interesting requirement (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 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 howthe "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
own object life time.
This relationship is called as the "Association"
relationship.
The third requirement from our list (Manager has workers who
work under him) denotes the same type ofrelationship like association but with
a difference that one of them is an owner. So as per the requirement the
"Manager" object will own "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 But....the "Worker" object can have his 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 the "Aggregation"
relationship.
The last two requirements are actually logically one. If you read closely both the requirements
which 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 same. In other words the project will not be
successful if the manager is not good and manager will not get good increments
if project has issues.
Below is how 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 as 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 garbage collected , or
putting from a different perspective the life time of the objects are same.
That's why I have put in the heading "Death" relationship.
Below is a visual representation of how the relationships have emerged from the
requirements.
You can also download source from ...
To avoid confusion hence forth in these 3 terms I have put forward a table
below which will help us compare them from
3 angles owner , life time and child object.
| Association | Aggregation | Composition |
Owner | No Owner | Single owner | Single Owner |
Life time | Have their own life time. | Have their own life time. | Owners life time |
Child object | No Child objects all are independent | Child objects belong to single parent. | Child objects belong to 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
lot more.