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,:
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:
Composition is usually implemented such that an object contains another object. For example,:
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:
Comments