In the world of
Object Oriented Programming language, Class is known as the basic building
block of an application. The class is kind of a container or capsule
or a cell, which encapsulate the set of methods, attribute and properties to provide
its indented functionalities to the outer world. Encapsulation is very basic
property of a Class which is responsible for hiding class data from outside
world. Encapsulation also controls the
exposure of function/properties of class so that it can be used/ consumed by
other class.
In order to
modularize/ define the functionality of a one class,
that class can uses functions/ properties exposed by
another class in many different ways. According to Object Oriented
Programming there are several techniques, classes can use to link with
each other and they are named Association, Aggregation, and Composition.
Objective
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.
Association
Association is the
simplest form of relationship between two classes. In Association type of
relation, all objects have their own lifecycle and there is no owner or
dependency between two classes.
For example
relation between a student and teacher is an Association. Multiple Students can
associate with a single Teacher and single Student can associate with
multiple Teachers, but there is no ownership between the objects and both have
their own lifecycle. Both can create and delete independently. Creation or
deletion of one object (Student) does not affect other object (Teacher). The Course (or Subject) object can combine
Student and Teacher in many to many relationships.
Aggregation
Aggregation is a
specialize form of Association where all object have their own lifecycle but
there is parent - child relationship between these objects (But this doesn’t
make true that child can’t be used by other Parent). Let’s take an example of
Department and Teacher. A single Teacher cannot belong to multiple Departments,
but if we delete the Department, Teacher object
will not destroy. We can think about “has-a” relationship.
Composition
Composition is a
strong type of Aggregation. Here the Parent and Child objects have coincident
lifetimes. Child object does not have its own lifecycle and if parent object
gets deleted, then all of its child objects will also be deleted. In short
child object depends on
parent object. Let’s take an example of relationship between House and Rooms.
House can contain multiple Rooms there is no independent life of Room and any Room
cannot belongs to two different houses. If
we delete the House, Room will
automatically delete.
|
Association
|
Aggregation
|
Composition
|
Owner
|
No owner
|
Single owner
|
Single owner
|
Life time
|
Have their own
lifetime
|
Have their own
lifetime
|
Owner's life time
|
Child object
|
Child objects
all are independent
|
Child objects
belong to a parent
|
Child objects belong to a single parent
|
Practical implementation
of Relationship type
When
we look at the real world through OOPs point of view, you will feel that these
real world objects have relationships and these relations are implemented
through 3 different ways i.e. Association, Aggregation and Composition.
Let’s consider
the simple requirement listed below:
1. Manager is an employee of XYZ Company.
2. Manager uses a swipe card to enter XYZ
premises.
3. Manager has workers who work under him.
4. Project success depends on Manager.
5. Manager's
incentive depends on project
success.
If you carefully
go through these five requirements, you can easily visualize four
relationships:-
· Inheritance [Is a]
· Association [uses]
· Aggregation [has]
· Cmposition [depends]
Let’s understand
them one by one.
Requirement 1: The “IS A” relationship: Inheritance
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: As the scope of
this article is only limited to aggregation, association, and composition, we will not discuss
inheritance in details.
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
Swipecard 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 “has” 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.
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 “depends” relationship: Composition
The
last two requirements are actually logically one. If you read closely, the
requirements are as follows: Project success depends on Manager and Manager's
incentive depends on project success.
So
the conclusion from analyzing the above requirements is that 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
incentive if the project fails.
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.
Conclusion
Association
or Aggregation or Compositions are all data access techniques which come under
Encapsulation. Use of Association,
Aggregation and Compositions techniques usually results in design practices
like
SOLID or
various
design
patterns.
The
point of using patterns, practices and such is to describe a solution to a
specific problem that is also maintainable and extensible. You simply based on
your experience and requirement to tell where to use which pattern or technique
to achieve your programming goals.