How to tell the difference between composition and aggregation association

[lowxizhi]

1) In this case, there is a composition association between Email class and Subject object. Subject object cannot exist after the Email object is deleted.

class Email { private Subject subject; ... }

2) In this case, there is an aggregation association between Team class and Person object. Person object can exist even after the Team object is deleted (Why is this so?).

class Team { Person leader; ... void setLeader(Person p) { leader = p; } }

Is the key difference how the part/containee object is declared in the whole/container class? Does declaring the object as a private variable result in composition association?

[lowxizhi]

Follow up question: Are composition and aggregation associations between

1. a class and a object
2. two classes
3. two objects ?

[damithc]

Side note: you can use fenced code blocks when posting code examples. https://help.github.com/en/github/writing-on-github/creating-and-highlighting-code-blocks

[brandoncjh]

I think it depends not so much on the access modifier but the level of encapsulation and whether the rest of the program outside the class has a reference to it. Taking an example from an SO post:

Composition

class Car {

  private final Engine engine;

  Car(EngineSpecs specs) {
    engine = new Engine(specs);
  }

  void move() {
    engine.work();
  }
}

Notice how the Car constructor creates an Engine object that exists only within the Car object. When the Car is destroyed, the Engine must be destroyed as well. (in your Email example, the Email and Subjects have a 'part-of' relationship meaning they co-depend on each other)

Aggregation

final class Car {

  private Engine engine;

  void setEngine(Engine engine) {
    this.engine = engine;
  }

  void move() {
    if (engine != null)
      engine.work();
  }
}

For this example, I can create a Car object at a certain time, then put in an Engine into that Car at a later time. The Engine object doesn't exist exclusively within the Car, and there is some way to reference it from outside. So when the Car is destroyed, the Engine can still exist and maybe be put into another Car. (like for your Team example, a Person can still live even if his Team is disbanded) In the example, there isn't a constructor but if there was, it probably wouldn't specify the Engine attribute at creation time.

I could be wrong, please feel free to correct me!

SO reference: https://stackoverflow.com/questions/11881552/implementation-difference-between-aggregation-and-composition-in-java

[dejunnn]

I have a related question regarding Composition and Aggregation. Based on the above example, its shown that there is an obvious difference between the 2, where

However, it was also mentioned in the textbook that the aggregation symbol can be omitted.

Would it be possible for an aggregation symbol to be replaced with a composition symbol? For example, in the example above, where a "whole-part" relationship is not present. Is replacing the aggregation with a composition be wrong in this case?

This also applies for the example in the textbook: where removing the club doesn't actually remove the person as well, and thus a whole-part relationship is not observed. Can the aggregation be replaced with a composition in this case?

[damithc]

Would it be possible for an aggregation symbol to be replaced with a composition symbol? For example, in the example above, where a "whole-part" relationship is not present. Is replacing the aggregation with a composition be wrong in this case?

don't use aggregation means use a normal association even if you think it is an aggregation (because there is no value added by making note of aggregation relationships, as they are implemented as normal associations anyway). It's doesn't mean use composition instead of aggregation.

[dejunnn]

Oh noted, thanks for the reply. So am I correct to assume that if we were told to not use aggregation we should in fact be replacing all non-whole-part relationships with normal associations? Which means that only strong whole-part relationships should be labelled with composition while all container-contained relationships are labelled with an aggregation/association?

[damithc]

Oh noted, thanks for the reply. So am I correct to assume that if we were told to not use aggregation we should in fact be replacing all non-whole-part relationships with normal associations? Which means that only strong whole-part relationships should be labelled with composition while all container-contained relationships are labelled with an aggregation/association?

That's correct.

[damithc]

@brandoncjh's answer is close to the mark.

Composition/aggregation is an additional information you provide about an association. A composition says the relationship is a whole-part relationship.

Note that it is not always possible to detect composition from the code alone as programming languages don't have a clean way to differentiate between composition, aggregation, and normal association. Therefore, in addition to clues in the code, you have to also consider addition information such as comments, you own knowledge of the domain. When not sure, just omit it as omitting composition/aggregation does not result in an incorrect diagram (it only results in a diagram with less information). In the exam, the question or the code comments will provide addition clues to help you decide if composition is expected to be used. If there is no such information given, both choices will be given the same marks.