OOPS concept: Difference between Composition and Aggregation

Composition:


As we know, inheritance gives us an 'is-a' relationship. To make the understanding of composition easier, we can say that composition gives us a 'part-of' relationship. Composition is shown on a UML diagram as a filled diamond

Let's take a simple example of a car, it would make sense to say that an engine is part-of a car. Within composition, the lifetime of the part (Engine) is managed by the whole (Car), in other words, when Car is destroyed, Engine is destroyed along with it. So how do we express this in C#?

C# Example:
public class Engine
{
   . . .
}

public class Car
{
   Engine e = new Engine();
   ......
}
As you can see in the example code above, Car manages the lifetime of Engine.

Aggregation:

If inheritance gives us 'is-a' and composition gives us 'part-of', we could argue that aggregation gives us a 'has-a' relationship. Within aggregation, the lifetime of the part is not managed by the whole. To make this clearer, let's see an example.
The CRM system has a database of customers and a separate database that holds all addresses within a geographic area. Aggregation would make sense in this situation, as a Customer 'has-a' Address. It wouldn't make sense to say that an Address is 'part-of' the Customer, because it isn't. Consider it this way, if the customer ceases to exist, does the address? I would argue that it does not cease to exist. Aggregation is shown on a UML diagram as an unfilled diamond

Concept of Aggregation by Example using C#   in C#? Well, it's a little different to composition. Consider the following code:

public class Address
{
  . . .
}

public class Person
{
    private Address address;
 
  public Person(Address address)
  {
    this.address = address;
}
    . .
}

Person would then be used as follows:

Address address = new Address();
Person person = new Person(address);
or
Person person = new Person( new Address() );

As you can see, Person does not manage the lifetime of Address. If Person is destroyed, the Address still exists. This scenario does map quite nicely to the real world.

Conclusion:
Making the decision on whether to use composition or aggregation should not be a tricky. When object modelling, it should be a matter of saying is this 'part-of' or does it 'have-a'?

Association:
1. A relationship between 2 objects that is not whole-part i.e. A contains a reference of B and uses B through the reference

2. Generally implemented as a public property of A, where B may be set in to A by an external party (say Spring)

Dependency:

1. A week association, where A doesnt contain a reference of B but uses B
2. Generally implemented as method parameter in A

Another definations for composition and aggregation.

Composition:
1. A strong whole-part relationship, i.e. B (child) has no existence outside A (parent)
2. A creates and contains B but B can not contain A

2. B must not be visible outside of A since if A dies, B must die

Aggregation:
1. A week whole-part relationship, i.e. B (child) may exist exist outside A (parent)
2. A contains B but B can not contain A
3. B must be visible outside of A since B may still exist when A dies
4. Generally 1-many relationship

Difference Between Composition and Aggregation in Object Oriented Programming?

In a composition relationship, the whole has sole responsibility for the disposition of its parts, or as you put it above, the whole "controls the lifetime of" the part. In order for the whole

to have "sole disposition" or "control the lifetime" of its parts, the whole must be the only object that knows of the parts existence.

C++ Code Example:

class Whole {
                     Part* part;
                   public:

                 Whole(): part( 0 ) { }

               ~Whole() { delete part; }

};

Part is created inside Whole class constructor and it is destroyed when whole is destroyed.

Let's take an Real Life Example:

University and Departments have a composition relationship. When University is created all the departments are created with it. When University is removed departments will not have the existance of their own.

In aggregation relationship, the part object reference can be re-used. Usually creation of part object is not the responsibility of the ‘whole ‘ object. It would have been created somewhere else, and passed to the ‘whole’ object as a method argument. Whole object will not have control on the lifetime of the part object.

class Whole {
Part* part;

public:

Whole() { }

~Whole() { }

};

Let's take a Real Life Example:

University and Professors are in aggregation relationship. When University is formed professors will come and join the University. But, when University is removed Professors will still exists and they can work in other Universities.

Let's have more definations so that you'll remember it life time.
Composition is composite aggregation, which means one object is a whole, none of its parts are shared with another part to create a similar object. To create a similar/matching object duplication of the whole object is necessary. Compostion, which is composite aggregation is a relationship in which, the parts of an object can belong only to the whole object. If one object lives the whole lives, if one object dies the whole dies.

Example: A stack of dominoes remains intake (alive) until one domino is moved, then the entire stack collapes (dies).

Aggregation is shared aggregation. The best example of which is a two rooms side-by-side share a common wall. If one room is damaged the other room remains intact because of the shared wall. Shared aggregation is one object, which is common to two similar objects.

Composition : Defines a strong-coupled relationship between  two entities, where the one entity is part of another, and  both need each other for their existence.
e.g. Human body  and the Heart.

Aggregation : Defines a weak-coupled relationship between two entities, where one entity could be part of another, but either can exist without the other, independently.
e.g.    School and teacher.

Composition can be used to model by-value aggregation which  is semantically equivalent to an attribute. In fact  composition was originally called aggregation-by-value in an earlier UML draft with “normal” aggregation being thought of  as aggregation-by-reference. The definitions have changed  slightly but the general ideas still apply. The distinction  between aggregation and composition is more of a design  concept and is not usually relevant during analysis.