Is it necessary for a composition not to be modified?

Question

I came across this answer while looking for a way to implement aggregation and composition in Java. Here's the answerer's implementation for composition -

final class Car {

  private final Engine engine;

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

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

I wanted to ask whether it is mandatory to declare engine as private final for it to be a valid composition? Does composition also imply that the attributes of engine will never change during its lifetime?

Attributes of the `Engine` instance can be changed in your implementation. You just can't change the engine itself. That's what the `final` does. — MockerTim, Sep 16 '14 at 15:56

My-Name-Is · Answer 1 · 2014-09-19T10:00:32.903

3

Short answer:

No!

Long answer:

The UML composition just means that the life time of the composite instance is tightly coupled to its superior instance. So there is no constraint which doesn't allow to exchange or modify the composite instance.

But kep the difference between aggregation and composition in mind!

Aggregation:

Supervisor -> Student (If the supervisor quits his job, the sudent may finish his education anyway)
Company -> Staff

Composition:

Building -> Room (If the building gets destroyed, the room is destroyed as well)
Company -> Department

edited Sep 19 '14 at 10:00

answered Sep 16 '14 at 15:43

My-Name-Is

4,814
10
44
84

So doesn't it mean that if I simply declare an object of type `Engine` in `Car`, it will become a composition and in any way not represent aggregation? – nsane Sep 16 '14 at 15:48
@nisargshah95 No! Ccompositions requires a specific implementation behaviour. The simple declaration of a class member follows the principle of aggregation, which means that if the life cycle of your class 'car' ends, the engine can survive somewhere else. Composition means that the life cycle of the 'engine' instance ends with the life cycle of 'car'. So composition requires, that you as a programmer have to make shure that all references of the 'engine' instance are set to 'null' if the life cycle of 'car' ends. Then all instances can be garbage collected and are destroyed afterwards. – My-Name-Is Sep 16 '14 at 15:56
But if `engine ` is a private member of `car`, wouldn't it be rendered useless immediately after `car` is destroyed? Or is it that Java implements both concepts in the same way but essentially they are different? – nsane Sep 16 '14 at 16:02
Java doesn't itself know about aggregation vs composition for object references. It just passes references around. You might be argue that an object holding a primitive represents composition in UML terms, since it's not held as a reference – Brian Agnew Sep 16 '14 at 16:04
http://ootips.org/uml-hasa.html holds good definitions for association, aggregation and composition. It is slightly different to what has been said here. Association means that there is a reference, aggregation that there is no reference cycles and as you have already said composition is about ownership/life cycle of the objects. – Chris K Sep 16 '14 at 16:09
Since both types of associations, aggregation and composition, represent part-whole relationship types, your Supervisor -> Student example is certainly not an aggregation (a student is not part of a supervisor). Also, a life time dependency is not the defining characteristic of composition, see this answer to another question: http://stackoverflow.com/questions/21951602/difference-between-composition-and-dependency-in-class-diagram/21975439#21975439 – Gerd Wagner Sep 18 '14 at 22:38
@gwag This always depends on the specific implementation. Of course a Supervisor doesn't own a student (hopefully), but it should just serve as an example. – My-Name-Is Sep 19 '14 at 08:21
@My-Name-Is: This is about concepts, not about implementations. Computational concepts are defined independently of their various kinds of implementations. – Gerd Wagner Sep 21 '14 at 14:06

score 2 · Answer 2 · answered Sep 16 '14 at 15:39

No. For example, a strategy pattern may permit the strategy to be swappable at run time, and the strategy is composed within another (context) class.

Immutability is a good pattern to follow, but some scenarios permit and/or require you to change composition. For example, how would you swap out the engine in your car when it blows up (above?)

score 1 · Answer 3 · answered Sep 16 '14 at 15:39

1

While immutability is a good design goal, it is not a requirement for composition to be considered 'valid'.

answered Sep 16 '14 at 15:39

Chris K

11,622
1
36
49

Is it necessary for a composition not to be modified?

3 Answers3