You are on page 1of 4

Definition

:

Aggregation is a relationship between two classes that is best described as a "has-a" and "whole/part" relationship.
It is a more specialized version of the association relationship. The aggregate class contains a reference to another
class and is said to have ownership of that class. Each class referenced is considered to be part-of the aggregate
class

Ownership occurs because there can be no cyclic references in an aggregation relationship. If Class A contains a
reference to Class B and Class B contains a reference to Class A then no clear ownership can be determined and
the relationship is simply one of association.

For example, imagine a Student class that stores information about individual students at a school. Now let's say
there is a Subject class that holds the details about a particular subject (e.g., history, geography). If the Student
class is defined to contain a Subject object then it can be said that the Student object has-a Subject object. The
Subject object also makes up part-of the Student object, after all there is no student without a subject to study.
The Student object is therefore the owner of the Subject object.

Examples:

There is an aggregation relationship between Student class and the Subject class:

public class Subject {

private String name;

public void setName(String name)
{
this.name = name;
}

public String getName()
{
return name;
}
}

public class Student {

private Subject[] studyAreas = new Subject[10];

//the rest of the Student class
}

Aggregation
Aggregation differs from ordinary composition in that it does not imply ownership. In
composition, when the owning object is destroyed, so are the contained objects. In aggregation,
this is not necessarily true. For example, a university owns various departments (e.g., chemistry),
and each department has a number of professors. If the university closes, the departments will no
longer exist, but the professors in those departments will continue to exist. Therefore, a
University can be seen as a composition of departments, whereas departments have an
aggregation of professors. In addition, a Professor could work in more than one department, but a
department could not be part of more than one university.

Composition is usually implemented such that an object contains another object. For example, in
C++:

class Professor;

class Department
{
...
private:
// Aggregation
Professor* members[5];
...
};

class University
{
...
private:
// Composition
Department faculty[20];
...
};

In aggregation, the object may only contain a reference or pointer to the object (and not have
lifetime responsibility for it):

Sometimes aggregation is referred to as composition when the distinction between ordinary
composition and aggregation is unimportant.

The above code would transform into the following UML Class diagram:
ct is one which contains other objects. For example, an Airplane class would contain Engine, Wing, Tail, Crew objects. Sometimes
the class aggregation corresponds to physical containment in the model (like the airplane). But sometimes it is more abstract (e.g.
Club and Members).

Whereas the test for inheritance is “isa”, the test for aggregation is to see if there is a whole/part relationship between two classes
(“hasa”). A synonym for this is “part-of”.

Being an aggregated object of some class means that objects of the containing class can message you to do work. Aggregation
provides an easy way ftwo objects to know about each other (and hence message each other). Can the contained object message
the container object? Is the relationship symmetrical?

Should the aggregation be done by value or by reference?

By value means that the lifetimes of the objects are exactly the same; they are born and die at the same time; they are inseparable
during their lifetimes. Aggregation by value cannot be cyclic: one object is the whole, one the part.

By reference de-couples the lifetimes of the two objects. The whole may not have a part, or it may have a different part at different
times. Different wholes may share the same part. De-allocating the whole won’t automatically de-allocate the part. Aggregation by
reference allows for the part to be aware of its whole.

Example

A List class may look like this. This list stores integers.

class List {
public:
List();
void addToFront(int);
int firstElement();
int length();
int includes(int);
void remove(int);
private:
// some data structure for
// storing integer elements
};

The List class could be quite handy for creating a new Set class, since the behavior is similar. One way to do this is to use a List
object to handle the data of the Set, via aggregation.

class Set {
public:
Set();
void add(int);
int size();
int includes(int);
private:
List data;
};

Now we can pretty easily implement Set in terms of the functionality available in List:
int Set::size() {
return data.length();
}

int Set::includes(int newValue) {
return data.includes(newValue);
}

void Set::add(int newValue)
{
if( ! includes(newValue) )
data.addToFront(newValue);
// else, no-op, since sets can only have
// one copy of any given value
}

This shows composition/aggregation by value, since the List element ivar of Set is statically declared. Every Set object always has a
List object. Delete a Set, the List goes away too, with no special action required.

Note that you need to worry about the List ivar object being properly initialized, so the constructor to Set must do this:

Set::Set() : data()
{
// other stuff for Set, as needed
}

The section on Inheritance will consider a design alternative for our implementation of Set.