Exploring Association, Aggregation, and Composition in OOP

Take advantage of association, aggregation and composition to define relationships between the objects in your application

Association Aggregation Composition in OOP

Association Aggregation Composition in OOP

The UML (Unified Modeling Language) 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 on the first three of these concepts, leaving the remaining ones in another blog post.

Association

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 life time 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 and at the same time, one patient can visit multiple doctors for treatment and/or consultation. Each of these objects have their own life-cycle and there is no owner. In other words, 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 (also known as cardinality) one-to-one, one-to-many and many-to-many. Essentially, an association relationship between two or more objects denote a path of communication (also called a link) between them so that one objects can send a message to another. The following code snippet illustrates how two classes IDGBlogAccount and IDGBlogEntry are associated to 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

Aggregation is a specialized form of association between two or more objects in which the objects have their own life-cycle but there exists an ownership as well. Aggregation is a typical whole/part relationship but it may or may not denote physical containment -- the objects may or may or be a part of the whole. In aggregation the objects have their own life-cycle but they do have ownership as well. As an example, an employee may belong to multiple departments in the organization. However, if the department is deleted, the employee object wouldn't be destroyed. Note that objects participating in an aggregation relationship cannot have cyclic aggregation relationships, i.e., a whole can contain a part but the reverse is not true. 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. Aggregation like association can be used to represent a one-to-many or many-to-many relationship between the participating objects due to which we may say that it is a redundant relationship.

Composition

Composition is a specialized form of aggregation in which if the parent object is destroyed, the child objects would cease to exist. It is actually a strong type of aggregation and is also referred to as a "death" relationship. As an example, a house is composed of one or more rooms. If the house is destroyed, all the rooms that are part of the house are also destroyed as they cannot exist by themselves. 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();

   }

}

In essence, Composition is also a whole/part relationship but unlike aggregation, here the lifetime of the "part" is controlled by the "whole". It should be noted that this control can either be direct or transitive, i.e., the "whole" may directly be responsible for creation or destruction of the "part" or it may use a "part" that has been already created and then delegate the control to some other "whole" to destroy the "part." 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.

Now that we have had a discussion on association, aggregation and composition relationships, let's understand how these three differ. It should be noted that aggregation and composition are both subsets of association. In both of these specific cases of association, an object or one class can be the owner of an object of another class. Note that in both aggregation and composition the child objects belong to a single parent object, i.e., there is a single owner.

This article is published as part of the IDG Contributor Network. Want to Join?

To comment on this article and other InfoWorld content, visit InfoWorld's LinkedIn page, Facebook page and Twitter stream.
From CIO: 8 Free Online Courses to Grow Your Tech Skills
Notice to our Readers
We're now using social media to take your comments and feedback. Learn more about this here.