Concept of Dependency, Generalization, Association, Aggregation, Composition in Object Oriented Programming

Designing an application using object oriented programming is inevitable due to the features it provides like inheritance, polymorphism, encapsulation etc. Apart from these concepts, it is very important to understand some logical concepts along with technical concepts so that writing the code is easy, clean & re-usable. In this article, we will be discussing some of the concepts, which we use in most of the classes that we write, but don’t even know that we have implemented a concept.

Relationships, as the name suggests itself, defines the dependency/association/same kind in the components of a system in real life. Same is the case with object oriented programming, which involve a lot of classes and most of these classes are somehow dependent/associated or similar to one or the other class. So broadly speaking, we have the concept of relationships with 3 categories :

  • Dependency –  also called as a using relationship, which means, one class dependent on another class.
  • Generalization – also called as a is-a-kind-of relationship
  • Association – also called as has-a relationship which says one class is somehow associated to another class

Association is a special kind of relationship and is further having two specialized concepts of Aggregation and Composition.

To discuss these concepts, I will be referring my understanding of my study, along with examples from the book named “The Unified Modeling Language User Guide” by Grady Booch, James Ramabaugh and Ivar Jacobson.

So let’s start with it.

Dependency :

Dependency is defined as relation between two classes, where one class depends on another class but another class may or not may depend on the first class.So any change in the one of the class, may affect the functionality of the other class, that depends on the first one.

For ex, we have a Customer class and an Order class. When we need to save a new order, we need to save it corresponding to a customer. In order to do so, our Order class will need a reference to the Customer class and save its data. So in this case, our Order class is dependent on the Customer class. In future, if any change is done in the Customer class, it may result change in Order class. See the code below :


In above code, we have CustomerId as Guid. Order class is using this customer instance. If we change the data type of the CustomerId from guid to integer, it will affect the Order class. This kind of relation is known as Dependency and is represented by the following symbol in UML representation :


Generalization : 

All of us know about the concept of inheritance. It is nothing but a kind of generalization. We define it is simply with a base class having some properties, functions etc. A new class will be derived from this base class and child class will have access to all the functionality of the base or parent class (of-course depending on the access modifiers defined on the base class members).

It is also referred to as “is-a-kind-of” or “is-a” relationship which means, the child class is-a-kind-of base class. This provides the ability to define common properties for derived classes at a common place and use them as per the derived class requirements.

For ex: we have a base class named Vehicle and a derived class named Car, from the base class. So Car will have access to all the functions, properties etc. of the base class Vehicle (depending on the access modifiers defined for base class members). See the code below :


Here we have common properties like color & price in base class which can be set as per derived class requirements. Apart from these, it will add its specific property named Discount. But this class will not be having access to the base class property VehicleType, as it is private type. Same will be applicable for any other class which derives from the Vehicle class and any other member defined in the base class. Generalization is represented by the following symbol in UML representation :


Association :

Association is defined as a structural relationship, which conceptually means that the two components are linked to each other. This kind of relation is also referred to as using relationship, where one class instance is using the other class instance or vice-versa, or both may be using each other.  But the main point is, the lifetime of the instances of two classes are independent of each other and there is no ownership between two classes. 

For ex : Consider the same example of  a Student-Teacher relationship. Conceptually speaking, each student can be associated to multiple teachers and each teacher can associate to multiple students. Now to discuss this relationship in terms of object oriented programming, see the code below :


Here, we have single student instance _student. This student can have multiple teacher class instances associated to it i.e. _teacher1 & _teacher2.

  1. Firstly, both these instances are getting created outside the student class. So their lifetime is independent of the lifetime of the instance of the student.  So even if _student is disposed explicitly, we can still have the teacher class instances as alive.
  2. Secondly,  any other student instance say _student2, can also have the same instances of teacher i.e. _teacher1 & _teacher2  associated to it. So we can also say, that no instance of student is parent of any instance of teacher. So there is no ownership of instances in the association.

Similarly, we can have reverse case, where we have a teacher instance _teacher1 and can associate _student1, _student2….etc. to it and the same student instances can be associated to another teacher instance, say _teacher2 .

Association is represented by the following symbol in UML representation :


So this was about association. Now comes the specialized cases of association i.e. aggregation & composition.

  • Aggregation : Aggregation is same as association but with an additional point that there is an ownership of the instances, unlike association where there was no ownership of the instances. To understand it better, let’s add another class named Department to our above discussed example .

If we talk about the relation between Teacher and Department, conceptually, a Department can have multiple Teachers associated to it but each Teacher can belong to only one Department, at a time. Now to discuss this relationship in terms of object oriented programming, see the code below :


Here, we have a department instance _department1 and multiple instances of teacher i.e. _teacher1 & _teacher2.

  1. Firstly, Lifetime of _teacher1 & _teacher2 instances are independent of lifetime of _department1 instance, as they are instantiated outside the department class. So even if _department1 instance is disposed, _teacher1 & _teacher2 instances may continue to exist.
  2. Secondly, _department1 can have multiple instances of teacher associated with it, but reverse is not true i.e. _teacher1 and _teacher2 can belong to _department1 only. They cannot belong to any other instance like department2. So _department1 becomes the owner of the _teacher1 & _teacher2 instances. So here the ownership exists.

Aggregation is also referred to as a Weak Association & is represented by the following symbol in UML representation :


  • Composition : This is same as that of aggregation, but with one additional point that the lifetime of the child instance is dependent on the owner or the parent class instance. To the same code above, let’s add another class named University.

So in this case also, conceptually, a university can have multiple departments in it. But, each department can belong to a single university only. Now to discuss this relationship in terms of object oriented programming, see the code below :


  1. Firstly, each department instance i.e. _department1 & _department2 can belong only to a single university instance at a time i.e. _university1. But a university instance can have multiple department instances attached to it. So this makes the _university1 instance as the owner of the _department1 & _department2 instances. So this is the inherited feature of the aggregation in composition.
  2. Secondly, here the lifetime of department instances are dependent on the instance of university, as they are getting created inside the university class. So when the _university1 instance is disposed, the _department1 & _department2 instances are also killed. This is the composition concept.

Composition is also referred to as Strong Association or Death relationship and is represented by the following symbol in UML representation :


So if we closely observe the concepts of Association, Aggregation & Composition, we can say that composition is subset of association & aggregation and aggregation is subset of association. To say it, Association is the super-set of aggregation and composition and can be represented as :


So this was all about these concepts and we can say that we were using these concepts in our programming but were not aware of their actual existence. One another concept that arises from this discussion is related to the concept of using either composition or inheritance, and will be covering in my further posts.

Hope you enjoyed reading it…!!!


About Jasminder

.Net developer and blogger by profession, keen to learn new technologies, love nature, music and cricket.
This entry was posted in Object Oriented Programming and tagged . Bookmark the permalink.

One Response to Concept of Dependency, Generalization, Association, Aggregation, Composition in Object Oriented Programming

  1. Very clear explanation with excellent examples!

I have a suggestion..

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s