Differentiate aggregation and composition relationship using source code

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

 public class Engine
{
    . . . 
}

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

AGGREGATION

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 o开发者_JAVA百科f 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?

---

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.

---

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.

---

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.