Composition vs. Aggregation

Composition vs. Aggregation

Aggregation and composition are both strong forms of association. They describe relationship between a whole and as its parts. So, instead of a has-a relationship as a simple association, we are dealing with a relationship says is part or reading the relationship in the other direction, is made up of.

Examples of these kind of relationship:

Orchestra: Musician
Orchestra is made up of Musicians
or Musician is part of Orchestra
Brochure: Product 
Brochure is made up of Products
or Product is part of Brochure
Building: Room
Building is made up of rooms
or Room is part of Building

Composition is even stronger relationship than aggregation. To test if we are dealing withcomposition, use no sharing rule for composition: part can belong to only one whole.

For the #1 and #2, part (Musician/Product) can belong only one (Orchestra/Catalog) whole? Yes! But for #3, room can belong to more than one building. No! No sharing rule applies to this case. So, the relationship #3 is better described by composition than by aggregation.

Besides the no sharing rule, another the rule for composition is: if the whole is destroyed, is the part that makes it up also destroyed?

Only the case #3 follows the additional composition rule. If orchestra breaks it up, will musicians be destroyed? No!

Code Example: A university owns various departments, 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.

• University - Department : composition: ownership: destroyed with the whole: strong has arelationship
  The composite object takes ownership of the component. This means the composite is responsible for the creation and destruction of the component parts. An object may only be part of one composite. If the composite object is destroyed, all the component parts must be destroyed.
  Composition enforces encapsulation as the component parts usually are members of the composite object:
  

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

• Department - Professors: aggregation: no ownership: may outlive: component may still have weakhas a relationship
  In aggregation, the object may only contain a reference or pointer to the object. The object may not have lifetime responsibility for the reference or pointer:

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

• Complete code example:

class Professor;
 
class Department
{
  ...
  private:
    // Aggregation
    Professor* members[5];
  ...
};
 
class University
{
  ...
  private:
 
    Department faculty[20];
  ...
 
  create dept()
  {
   ....
     // Composition
     faculty[0]= Department(....);
     faculty[1]= Department(....);
   ....   
  }
};

Source of the code and diagrams: wiki

 

In UML, composition is depicted as a filled diamond and a solid line. It always implies a multiplicity of 1 or 0..1, as no more than one object at a time can have lifetime responsibility for another object. The more general form, aggregation, is depicted as an unfilled diamond and a solid line. The image above shows both composition and aggregation. 

ref :http://www.bogotobogo.com/DesignPatterns/introduction.php