Association, Aggregation and Composition PART II

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:

1. Manager is an employee of XYZ limited corporation.
2. Manager uses a swipe card to enter XYZ premises.
3. Manager has workers who work under him.
4. Manager has the responsibility of ensuring that the project is successful.
5. 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 was discuss earlier in my blog.

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:

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

Below is the conclusion from analyzing the above requirements:

1. Manager and the project objects are dependent on each other.
2. 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.

Summarizing

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

	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 single parent	Child objects belong to a single parent

Realization

Realization is a relationship between the blueprint class and the object containing its respective implementation level details. This object is said to realize the blueprint class. In other words, you can understand this as the relationship between the interface and the implementing class.

Example: A particular model of a car ‘GTB Fiorano’ that implements the blueprint of a car realizes the abstraction.

Dependency

Change in structure or behaviour of a class affects the other related class, then there is a dependency between those two classes. It need not be the same vice-versa. When one class contains the other class it this happens.

Example: Relationship between shape and circle is dependency.

  

Aggregation VS Composition

Aggregation	Composition
Aggregation is a special type of Association.	Composition is a special type of Aggregation.
All objects have their own life cycle.	In Composition, the child object does not have their own life cycle and it depends on the parent's life cycle.
A parent class is not responsible for creating or destroying the child class.	The parent class is responsible for creating or destroying the child class.
Aggregation can be described as a "Has-a" relationship.	Composition can be described as a "Has-a" relationship as well as a "Part of" relationship, but here the difference is the length of the relationship among the objects.
Aggregation is a weak Association.	Composition is a strong Association.
Aggregation means one object is the owner of another object.	Composition means one object is contained in another object.
The direction of a relation is a requirement in both Composition and Aggregation. The direction specifies which object contains the other one.
Both have a single direction of association.
Both have a single owner.

05.2. Kinds of Association:

There are two main types of association which are then further subdivided i.e

1. Class Association

2. Object Association

1. Class Association

Class association is implemented in terms of Inheritance. Inheritance implements

generalization/specialization relationship between objects. Inheritance is considered

class association.

• In case of public inheritance it is “IS-A” relationship.

• In case of private inheritance it is “Implemented in terms of” relationship.

This relationship ensures that public members of base class are available to derived

class in case of public inheritance.

When we create objects of classes in which we have implemented inheritance

relationships we are forcing the inheritance relationship between created objects. In

this case the derived class objects will also contain base class objects attributes and

methods.

2. Object Association

It is the interaction of stand alone objects of one class with other objects of anther

class.

It can be of one of the following types,

• Simple Association

• Composition

• Aggregation

05.3. Simple Association

The two interacting objects have no intrinsic relationship with other object. It is the

weakest link between objects. It is a reference by which one object can interact with

some other object.

Customer gets cash from cashier

Employee works for a company

Ali lives in a house

Ali drives a car

It is generally called as “association” instead of “simple association”

Kinds of Simple Association

Simple association can be categorized in two ways,

• With respect to direction (navigation)

• With respect to number of objects (cardinality)

Kinds of Simple Association w.r.t Navigation

With respect to navigation association has the following types,

a. One-way Association

b. Two-way Association

a. One-way Association

In One way association we can navigate along a single direction only, it is denoted

by an arrow towards the server object.

Examples:

• Ali lives in a House

• Ali drives his Car

b. Two-way Association

In two way association we can navigate in both directions, it is denoted by a line

between the associated objects

Examples:

Employee works for company

Company employs employees

Two-way Association – Example

Object Oriented Programming (CS304) VU

© Virtual University of Pakistan 51

Yasir is a friend of Ali

Ali is a friend of Yasir

Kinds of Simple Association w.r.t Cardinality

With respect to cardinality association has the following types,

a. Binary Association

b. Ternary Association

c. N-ary Association

a. Binary Association

It associates objects of exactly two classes; it is denoted by a line, or an arrow

between the associated objects.

Example

Association “works-for” associates objects of exactly two classes

Association “drives” associates objects of exactly two classes

b. Ternary Association

It associates objects of exactly three classes; it is denoted by a diamond with lines

connected to associated objects.

Example

Objects of exactly three classes are associated

Object Oriented Programming (CS304) VU

© Virtual University 52 of Pakistan

c. N-ary Association

An association between 3 or more classes its practical examples are very rare.

05.4. Composition

An object may be composed of other smaller objects, the relationship between the

“part” objects and the “whole” object is known as Composition, Composition is

represented by a line with a filled-diamond head towards the composer object

Example – Composition of Ali

Example – Composition of Chair

Object Oriented Programming (CS304) VU

© Virtual University of Pakistan 53

Composition is stronger relationship:

Composition is a stronger relationship, because

Composed object becomes a part of the composer

Composed object can’t exist independently

Example I

Ali is made up of different body parts

They can’t exist independent of Ali

Example II

Chair’s body is made up of different parts

They can’t exist independently

05.5. Aggregation

An object may contain a collection (aggregate) of other objects, the relationship

between the container and the contained object is called aggregation, Aggregation is

represented by a line with unfilled-diamond head towards the container

Object Oriented Programming (CS304) VU

© Virtual University 54 of Pakistan

Example – Aggregation

Aggregation is weaker relationship

Aggregation is weaker relationship, because

• Aggregate object is not a part of the container

• Aggregate object can exist independently

Example I

Furniture is not an intrinsic part of room

Furniture can be shifted to another room, and so can exist independent of a

particular room

Example II

A plant is not an intrinsic part of a garden

It can be planted in some other garden, and so can exist independent of a particular

garden

        static void Main(string[] args)

        {

            #region Composition

            Manager _Manager = new Manager();

            Project _Project = new Project(_Manager);

            _Project.HasIssues(false);

            #endregion

            #region Aggregation

            List<Worker> _WorkerList = new List<Worker>();

            _WorkerList.Add(new Worker { ID = 1, Name = "Ghazanfar", PhoneNo = "01234", Salary = 50000.00f });

            _WorkerList.Add(new Worker { ID = 2, Name = "Ali", PhoneNo = "987654", Salary = 60000.00f });

            _WorkerList.Add(new Worker { ID = 3, Name = "Ghazi", PhoneNo = "456456", Salary = 55000.00f });

            Manager _Manager = new Manager();

            /*_Manager = null;*/

            #region Comments

            //Employee is still exist even the Manager Class object is destroy (set to null)

            //This Relationship is called Aggregation

            //It is same as Association but in Aggregation case there is one of them is owner

            //So, Manager object has the Worker Object

            //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.

            #endregion

            //_Manager.AddWorker(_WorkerList);

            #endregion

            #region Association

            SwapCard _SwapCard = new SwapCard();

            Manager _Manager = new Manager();

            //Swap Methods

            Console.WriteLine(_SwapCard.CreateNewCard());

            _SwapCard.Swap(_Manager);

            //_SwapCard = null;

            //Manaer Methods

            _Manager.isGoodPerson(true);

            ////_Manager.CheckIn(_SwapCard);

            #endregion

     #region Inheritance

            //Employee is Parent class. Manager and Worker inherited it

            #endregion

            //General

            Console.WriteLine("Press any key to continue...");

            Console.ReadKey();

        }

      }

Summarizing

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

	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 single parent	Child objects belong to a single parent

(Practice Makes a Man Perfect)