Skip to content

Decorator: Composition instead of Aggregation #1095

@dgruntz

Description

@dgruntz

In issue #518 it was proposed to change the relationship between decorator and target (in the code example between Troll und SmartTroll) from a composition to an aggregation with the argumentation that in a composition both instances cannot live without the other one. I disagree with this argumentation and I just checked the UML spec from OMG (available at https://www.omg.org/spec/UML/2.5.1/). An example in the UML spec are wheels which are part of a car (composition), but wheels can exist without a car (in particular I just exchanged my summer wheels with winter wheels).

The spec states:

Composite aggregation is a strong form of aggregation that requires a part object be included in at most one composite object at a time. If a composite object is deleted, all of its part instances that are objects are deleted with it.
NOTE. A part object may (where otherwise allowed) be removed from a composite object before the composite object is deleted, and thus not be deleted as part of the composite object.

The main properties are that

  1. a part may be part of at most one composite. I think that this holds for the decorator pattern, i.e. you can't decorate an instance with two different decorators, but rather the idea is that the original reference is replaced with the reference to the decorator.
  2. deleting an object in one part of the graph will also result in the deletion of all objects of the subgraph below that object. But this holds for the decorator as well, i.e. if you release the smart troll instance, then the troll instance is released as well.

Therefore I recommend to switch back from aggregation to composition.

Best wishes
Dominik

Metadata

Metadata

Assignees

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions