5

Is it possible to differentiate between composition and aggregation relationship by reading the source code?

I tried to find some patterns and I have listed them below.

I am taking the example from this site just to explain what I assume to be a pattern

COMPOSITION

enter image description here

 public class Engine
{
    . . . 
}

public class Car
{
   Engine e = new Engine();
    .......
}

AGGREGATION

enter image description here

public class Address
{
. . .
}

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

I find these patterns to differentiate

COMPOSITION (is a part of )

  1. Defined as a field of a class.

    • Example: [Engine e] Engine is defined as a field e of the class Car

  2. Instantiated and assigned within the class.

    • Example: [Engine e = new Engine();] Engine is instantiated inside the class

Aggregation (has a)

  1. Defined as a field of a class

    • Example: [private Address address;] Address is defined as a field address of the class Person

  2. Instatiated out side the class

    • Example: [Address address = new Address();] Address is instatiated outside Person.

  3. Assigned in the constructor by sending the instance as a argument to the constructor.

    • Example: [Person person = new Person(address);] The instance of Address is passed as an argument through the constructor and assigned in the constructor of the class Person.

CAN I CONSIDER THESE TO DIFFERENTIATE AGGREGATION AND COMPOSITION RELATION?

ARE THERE MORE CONSTRAINTS THAT ARE USED TO DIFFERENTIATE?

Sachin
  • 155
  • 1
  • 8

3 Answers3

1

Not really, because there's not a unique way to implement each kind of association (in fact, the problem is that we have three kinds of associations, "normal associations", "aggregations" and "compositions").

If the language has pointers then you could try to guess that if Engine is defined in Car as a pointer then the programmer that wrote that piece of code is suggesting a softer relationship (aggregation or association) between Cars and Engines since removing the Car does not imply losing the Engine object.

Jordi Cabot
  • 8,058
  • 2
  • 33
  • 39
  • I agree with you that pointers would lead to confusion in guessing the association relations. What if we consider a language like C# or Java where we do not have pointers? Do we get any other common patterns as I have listed? – Sachin Jul 21 '11 at 17:09
  • 1
    IF there are no pointers, then things get much more difficult. The only thing we could do is to check the behaviour of the methods. For instance if Engine is created inside the constructor method of Car, this would also suggest a composition. But there are no guarantees, just heuristics – Jordi Cabot Jul 21 '11 at 22:09
  • 1
    COMPOSITION: the object is instantiated in the CONTAINED class. AGGREGATION: Instantiated and injected to the class. So if the engine is created within the class Car then it will be destroyed when the Car object is destroyed...So it should be composition, so i feel we can differentiate by checking where the instantiation takes place. In case of aggregation, the object Engine should not be destroyed if an instance of class Car is destroyed. So engine will be instantiated outside the class or in a static method. – Sachin Jul 22 '11 at 08:18
1

You may check this similar question (not mine), the answer marked as "prefered" / "acepted" is mine ;-)

Aggregation and Composition representation in class definition?

It depends, if the person that build that code, did apply those design patterns.

Community
  • 1
  • 1
umlcat
  • 4,091
  • 3
  • 19
  • 29
  • 1
    Yes, the pattern holds. In UniversityClass, **COMPOSITION** Department instance is created within the Class in addDepartment method.(so both my rules in composition holds). **AGGREGATION** ProfessorClass instance is created in a static method and passed as an argument to be assigned to the Professor Field. So I should consider the use of shared (static) methods. Thank You for the link. – Sachin Jul 22 '11 at 07:58
0

Association

Association is a relationship where all object have their own lifecycle and there is no owner. Let’s take an example of Teacher and Student. Multiple students can associate with single teacher and single student can associate with multiple teachers but there is no ownership between the objects and both have their own lifecycle. Both can create and delete independently.

Aggregation

Aggregation is a specialize form of Association where all object have their own life-cycle but there is ownership and child object can not belongs to another parent object. Let’s take an example of Department and teacher. A single teacher can not belongs to multiple departments, but if we delete the department teacher object will not destroy. We can think about “has-a” relationship.

Composition

Composition is again specialize form of Aggregation and we can call this as a “death” relationship. It is a strong type of Aggregation. Child object dose not have their life-cycle and if parent object deletes all child object will also be deleted. Let’s take again an example of relationship between House and rooms. House can contain multiple rooms there is no independent life of room and any room can not belongs to two different house if we delete the house room will automatically delete.

So, I don't think the relation between the car and the engine be Composition, because engine could exists without the car, I think the relation between Car and engine is Aggregation.

Long story short; yeah by reading the code you could determine type of the relationship(composition and aggregation; but i'm not sure the association) according the definitions, and i think your patterns for differentiate are correct.

Masoud
  • 8,020
  • 12
  • 62
  • 123