15E604 Data Structures and Algorithms

ASSOCIATION, AGGREGATION
AND COMPOSITION
Abinaya 18E102
Samyuktha V 18E145
ASSOCIATION
ASSOCIATION
Association, aggregation, and composition to define
relationships between the objects in your application

There are five different types of relationships:

association, aggregation, composition, dependency,
and inheritance.

 Association is a semantically weak relationship (a

semantic dependency) between otherwise unrelated
objects.
ASSOCIATION
An association is a “using” relationship between two or more objects in
which the objects have their own lifetime and there is no owner.

Association is a relationship among the objects.

In Association, the relationship among the objects determine what an

object instance can cause another to perform an action on its behalf.
ASSOCIATION
We can also say that an association defines the multiplicity among the
objects. We can define a one-to-one, one-to-many, many-to-one and many-to-
many relationship among objects.

Association is a more general term to define a relationship among objects.

Association means that an object "uses" another object.
ASSOCIATION
Here, the lives of both objects are independent of each other.

That means that in this Association (Aggregation) the object has their own
life cycle.

Employees may exist without a department. Here, department can be called

an owner object and the employee can be called a child object.

 The owner and child objects cannot belong to a different parent object.
ASSOCIATION
To qualify as an association, an object and another object must have the following
relationship:

• The associated object (member) is otherwise unrelated to the object (class)

• The associated object (member) can belong to more than one object (class) at a time
• The associated object (member) does not have its existence managed by the object (class)
• The associated object (member) may or may not know about the existence of the object
(class)
EXAMPLE 1
As an example, imagine the relationship between a doctor and a patient.

A doctor can be associated with multiple patients.

At the same time, one patient can visit multiple doctors for treatment or consultation. Each of
these objects has its own life cycle and there is no “owner” or parent.

The objects that are part of the association relationship can be created and destroyed
independently.
EXAMPLE 2
For example Managers and Employees, multiple employees may be associated with a single
manager and a single employee may be associated with multiple managers.

          
COMPARISON
ASSOCIATION AGGREGATION COMPOSITION

OWNER No owner Single owner Single owner

LIFETIME Have their own life time Have their own life time Owners life time

CHILD OBJECT No child objects all are Child objects belong to Child objects belong to
independent single parent single parent
ASSOCIATION
Unlike a composition or aggregation, where the part is a part of the whole object, in an
association, the associated object is otherwise unrelated to the object.

Just like an aggregation, the associated object can belong to multiple objects simultaneously, and
isn’t managed by those objects.

 However, unlike an aggregation, where the relationship is always unidirectional, in an

association, the relationship may be unidirectional or bidirectional (where the two objects are
aware of each other).
IMPLEMENTATION OF
ASSOCIATION
IMPLEMENTATION OF DOCTOR/PATIENT
RELATIONSHIP

Because associations are a broad type of relationship, they can be implemented in many different
ways.

 However, most often, associations are implemented using pointers, where the object points at
the associated object.

In this example, we’ll implement a bi-directional Doctor/Patient relationship, since it makes
sense for the Doctors to know who their Patients are, and vice-versa.
#include <cstdint>
#include <functional> // reference_wrapper
#include <iostream>
#include <string>
#include <vector>
 
// Since Doctor and Patient have a circular dependency, we're
going to forward declare Patient
class Patient;
 
class Doctor
{
private:
std::string m_name{};
std::vector<std::reference_wrapper<const Patient>>
m_patient{};
 
public:
Doctor(const std::string& name) :
m_name{ name }
{
}
 
void addPatient(Patient& patient);
// We'll implement this function below Patient since we
need Patient to be defined at that point
friend std::ostream& operator<<(std::ostream &out,
const Doctor &doctor);
 
const std::string& getName() const { return m_name; }
};
 
class Patient
{
private:
std::string m_name{};
std::vector<std::reference_wrapper<const Doctor>> m_doctor{};
// so that we can use it here
 
// We're going to make addDoctor private because we don't want
the public to use it.
// They should use Doctor::addPatient() instead, which is
publicly exposed
void addDoctor(const Doctor& doctor)
{
m_doctor.push_back(doctor);
}
public:
Patient(const std::string& name)
: m_name{ name }
{
}
// We'll implement this function below Doctor since we need Doctor to
be defined at that point
friend std::ostream& operator<<(std::ostream &out, const Patient
&patient);
 
const std::string& getName() const { return m_name; }
 
// We'll friend Doctor::addPatient() so it can access the private function
Patient::addDoctor()
friend void Doctor::addPatient(Patient& patient);
};
 
void Doctor::addPatient(Patient& patient)
{
// Our doctor will add this patient
m_patient.push_back(patient);
 
// and the patient will also add this doctor
patient.addDoctor(*this);
}
 
std::ostream& operator<<(std::ostream &out, const
Patient &patient)
{
if (patient.m_doctor.empty())
{
out << patient.getName() << " has no doctors right
now";
return out;
}

out << patient.m_name << " is seeing doctors: ";

for (const auto& doctor : patient.m_doctor)
out << doctor.get().getName() << ' ';
 
return out;
} 
int main()
{
// Create a Patient outside the scope of the Doctor
Patient dave{ "Dave" };
Patient frank{ "Frank" };
Patient betsy{ "Betsy" };
 
Doctor james{ "James" };
Doctor scott{ "Scott" };
 
james.addPatient(dave);
 
scott.addPatient(dave);
scott.addPatient(betsy);
 
std::cout << james << '\n';
std::cout << scott << '\n';
std::cout << dave << '\n';
std::cout << frank << '\n';
std::cout << betsy << '\n';
 
return 0;
}
This prints:

James is seeing patients: Dave Scott is seeing patients:

Dave Betsy Dave is seeing doctors: James Scott Frank has
no doctors right now Betsy is seeing doctors: Scott
EXPLANATION
The doctor clearly has a relationship with his patients, but conceptually it’s not a part/whole
(object composition) relationship.

 A doctor can see many patients in a day, and a patient can see many doctors (perhaps they want
a second opinion, or they are visiting different types of doctors).

Neither of the object’s lifespans are tied to the other.We can say that association models as “uses-
a” relationship.

 The doctor “uses” the patient (to earn income). The patient uses the doctor (for whatever health
purposes they need).
REFLEXIVE ASSOCIATION
 Sometimes objects may have a relationship with other objects of the same type.
 This is called a reflexive association.
 A good example of a reflexive association is the relationship between a university course
and its prerequisites (which are also university courses).
 Consider the simplified case where a Course can only have one prerequisite. We can do
something like this:
 This can lead to a chain of associations (a course has a prerequisite, which has a
prerequisite)
 ASSOCIATIONS CAN BE INDIRECT
In all of the previous cases, we’ve used either pointers or references to directly link objects

together.

 However, in an association, this is not strictly required. Any kind of data that allows you to

link two objects together suffices.

1 #include <string>
2 class Course
3{
4 private:
5     std::string m_name;
6     const Course *m_prerequisite;
7 
8 public:
9     Course(const std::string &name, const Course *prerequisite =
1 nullptr):
0         m_name{ name }, m_prerequisite{ prerequisite }
1     {
1     }
1 
2 };
1
3
1
4
AGGREGATION
AGGREGATION
Aggregation is a specialized form of association between two or more objects in which each object

has its own life cycle but there exists an ownership as well.

 Aggregation is a typical whole/part or parent/child relationship but it may or may not denote

physical containment.

 An essential property of an aggregation relationship is that the whole or parent (i.e. the owner) can

exist without the part or child and vice versa.  

AGGREGATION
Aggregation is a special type of Association. Aggregation is "*the*" relationship among objects.

We can say it is a direct association among the objects. In Aggregation, the direction specifies

which object contains the other object.

There are mutual dependencies among objects.

EXAMPLE 1
As an example, an employee may belong to one or more departments in an organization.

However, if an employee’s department is deleted, the employee object would not be destroyed
but would live on.

Note that the relationships between objects participating in an aggregation cannot be reciprocal
—i.e., a department may “own” an employee, but the employee does not own the department.
EXAMPLE 2
 For example, departments and employees, a department has many employees but a single
employee is not associated with multiple departments.
 UML Representation of Aggregation (white diamond):

 The UML representation of the example above (relation between employee and department):

              
Aggregation implementation
To qualify as an aggregation, a whole object and its parts must have the
following relationship:

 The part (member) is part of the object (class)

 The part (member) can belong to more than one object (class) at a time

 The part (member) does not have its existence managed by the object (class)

 The part (member) does not know about the existence of the object (class)
AGGREGATION
 Like a composition, an aggregation is still a part-whole relationship, where the parts are

contained within the whole.

 It is a unidirectional relationship.

 However, unlike a composition, parts can belong to more than one object at a time, and

the whole object is not responsible for the existence and lifespan of the parts.
AGGREGATION
 When an aggregation is created, the aggregation is not responsible for

creating the parts.

 When an aggregation is destroyed, the aggregation is not responsible for

destroying the parts.

 In an aggregation, we also add parts as member variables.

 However, these member variables are typically either references or pointers that are

used to point at objects that have been created outside the scope of the class.

 Consequently, an aggregation usually either takes the objects it is going to point to as

constructor parameters, or it begins empty and the sub-objects are added later via

access functions or operators.

Because these parts exist outside of the scope of the class, when the class is

destroyed, the pointer or reference member variable will be destroyed (but

not deleted).

Consequently, the parts themselves will still exist.

Example-1
 For example, consider the relationship between a person and their home

address.

 In this example, for simplicity, we’ll say every person has an address.

However, that address can belong to more than one person at a time, for

example consider to both you and your family or significant other.

 However, that address isn’t managed by the person, the address probably

existed before the person got there, and will exist after the person is gone.

 Additionally, a person knows what address they live at, but the addresses

don’t know what people live there. Therefore, this is an aggregate

relationship.
Example - 2
Example - 3
 Consider a car and an engine.

 A car engine is part of the car.

 And although the engine belongs to the car, it can belong to other things as

well, like the person who owns the car.

The car is not responsible for the creation or destruction of the engine.

And while the car knows it has an engine (it has to in order to get

anywhere) the engine doesn’t know it’s part of the car.

Example - 4
Let’s consider a Teacher and Department example in more detail.

In this example, we’re going to make a couple of simplifications:

First, the department will only hold one teacher.

Second, the teacher will be unaware of what department they’re part of.
In C++
Code Explaination
In this case, bob is created independently of department, and then passed

into department‘s constructor.

When department is destroyed, the m_teacher reference is destroyed

But the teacher itself is not destroyed, so it still exists until it is independently

destroyed later in main().

COMPOSITION
Composition
 Composition is a restricted form of Aggregation in which two entities are highly dependent on

each other.

 It represents part-of relationship.

 In composition, both the entities are dependent on each other.

 When there is a composition between two entities, the composed

 Object cannot exist without the other entity.

Composition
 In a composition relationship, the object is responsible for the existence of the parts.

 Most often, this means the part is created when the object is created, and destroyed

when the object is destroyed.

 But more broadly, it means the object manages the part’s lifetime in such a way that

the user of the object does not need to get involved.

Composition
Composition is sometimes called a “death relationship”.

The part doesn’t know about the existence of the whole.

This a unidirectional relationship
Composition
 Member-objects of a class are constructed:

 In the order they are declared

 Not in the order they are listed in the constructor’s member

initialization list

 Before the enclosing class objects are constructed

Composition Implementation
To qualify as a composition, an object and a part must have the following relationship:

 The part (member) is part of the object (class)

 The part (member) can only belong to one object (class) at a time

 The part (member) has its existence managed by the object (class)

 The part (member) does not know about the existence of the object (class)
Example - 1
 A good real-life example of a composition is the relationship between a

person’s body and a brain.

 For example, a brain is a part of a person’s body.

 The part in a composition can only be part of one object at a time.

Example - 1
The brain that is part of one person’s body can not be part of someone else’s

body at the same time.

When a body is created, the brain is created too. When a person’s body is

destroyed, their brain is destroyed too. 

Example - 2
Example - 3
Many games and simulations have creatures or objects that move around a board, map, or

screen.

One thing that all of these creatures/objects have in common is that they all have a location.

In this example, we are going to create a creature class that uses a point class to hold the

creature’s location.
Example - 3
 First, let’s design the point class.

 Our creature is going to live in a 2d world, so our point class will have 2

dimensions, X and Y.

 We will assume the world is made up of discrete squares, so these dimensions

will always be integers.

Example - 3
We are going to implement all of our functions in the header file

This Creature is also a composition of its parts.

The creature’s name and location have one parent, and their lifetime is tied to

that of the Creature they are part of.

Output
Example - 4
This class has two data members: a numerator and a denominator.

The numerator and denominator are part of the Fraction (contained with in

it).

 They can not belong to more than one Fraction at a time.

Example - 4
The numerator and denominator don’t know they are part of a Fraction, they just

hold integers.

When a Fraction instance is created, the numerator and denominator are created.

When the fraction instance is destroyed, the numerator and denominator are

destroyed as well.
Association vs Aggregation vs
Composition
THANK YOU!