Association, aggregation, and composition in OOP explained

The Unified Modeling Language (UML) is a de facto standard for modeling object-oriented systems. In UML there are five different types of relationships: association, aggregation, composition, dependency, and inheritance. This article presents a discussion of the first three of these concepts, leaving the remaining ones to another blog post.

Association in object oriented programming

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

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.

In UML an association relationship is represented by a single arrow. An association relationship can be represented as one-to-one, one-to-many, or many-to-many (also known as cardinality). Essentially, an association relationship between two or more objects denotes a path of communication (also called a link) between them so that one object can send a message to another. The following code snippet illustrates how two classes, IDGBlogAccount and IDGBlogEntry, are associated with one another.

public class IDGBlogAccount
   {
       private IDGBlogEntry[] blogEntries;
       //Other members of the IDGBlogAccount class
   }
public class IDGBlogEntry
   {
       Int32 blogId;
       string caption;
       string text;
       //Other members of the IDGBlogEntry class
   }

Aggregation in object oriented programming

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.  

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. In the following code example, an aggregation relationship is evident between the IDGBlogAuthor and IDGBlogAccount classes.

public class IDGBlogAuthor
   {
       private Int32 authorId;
       private string firstName;
       private string lastName;
       //Other members of the IDGBlogAuthor class
   }
public class IDGBlogAccount
   {
       private IDGBlogEntry[] blogEntries;
       //Other members of the IDGBlogAccount class
   }

Aggregation is usually represented in UML using a line with a hollow diamond. Like association, aggregation can involve a one-to-one, one-to-many, or many-to-many relationship between the participating objects. In the case of a one-to-many or many-to-many relationship, we may say that it is a redundant relationship.

Composition in object oriented programming

Composition is a specialized form of aggregation. In composition, if the parent object is destroyed, then the child objects also cease to exist. Composition is actually a strong type of aggregation and is sometimes referred to as a “death” relationship. As an example, a house may be composed of one or more rooms. If the house is destroyed, then all of the rooms that are part of the house are also destroyed. The following code snippet illustrates a composition relationship between two classes, House and Room.

public class House
{
   private Room room;
   public House()
   {
       room = new Room();
   }
}

Like aggregation, composition is also a whole/part or parent/child relationship. However, in composition the life cycle of the part or child is controlled by the whole or parent that owns it. It should be noted that this control can either be direct or transitive. That is, the parent may be directly responsible for the creation or destruction of the child or the parent may use a child that has been already created. Similarly, a parent object might delegate the control to some other parent to destroy the child object. Composition is represented in UML using a line connecting the objects with a solid diamond at the end of the object that owns the other object.

I hope this discussion of association, aggregation, and composition relationships has helped you understand how these three concepts differ. Remember that aggregation and composition are both subsets of association. In both aggregation and composition, an object of one class can be the owner of an object of another class. And in both aggregation and composition, the child objects belong to a single parent object, i.e., they may have only one owner.

Finally, in an aggregation relationship, the life cycles of parent objects and child objects are independent. In a composition relationship, the death of a parent object also means the death of its children.