Search code examples
inheritancedesign-patternsumlcomposition

What does composition mean in the composition vs inheritance debate?

I was learning about the Bridge Design pattern. To quote:

The Bridge pattern attempts to solve this problem by switching from inheritance to the object composition. …

And then, the following image is shown:

Bridge Pattern

When people are talking about composition as an alternative for inheritance, do they refer to both aggregation and composition relationships? If not, what do they mean exactly?

I wonder this because the picture has an aggregation relationship between Color and Shape, not a composition one.

Solution

  • In short

    This is a terminological ambiguity. Almost all articles on the bridge pattern are directly inspired from the Gang of Four (GoF) who first defined this design pattern. And this is the cause of the ambiguity:

    • They used the term composition to mean object composition and not UML composition.

    • At the time they wrote their book, UML was not yet defined. Their graphical notation uses the hollow diamond with a different meaning than UML.

    • They were first to mention composition over inheritance, with the meaning of object composition as opposed to class inheritance.

    More details

    GoF's object composition is not UML composition

    Object composition is the OOP technique that aims at making more complex objects by assembling simpler objects. It's defined on page 19 of the book:

    Here, new functionality is obtained by assembling or composing objects to get more complex functionality. Object composition requires that the objects being composed have well-defined interfaces. This style of reuse is called black-box reuse, because no internal details of the objects are visible.

    In UML this technique corresponds to the implementation of an association, a shared aggregation or an UML composition. But unlike UML composition, it does not imply exclusive ownership nor lifecycle management.

    GoF graphical notation is not UML

    The graphical notation of class diagram used in the book looks very much like UML. This is because it is based on OMT, a predecessor of UML. But there are slight differences in the use of symbols, as you can read on page 364 of GoF:

    An object reference representing a part-of or aggregation relationship is indicated by an arrowheadded line with a diamond at its base.

    In UML, a composition (black diamond) would match this definition. But UML-composition adds more requirement, such as an exclusive ownership and responsibility for the component's lifecycle. This is more restrictive than object composition and reference-based aggragation.

    In UML a shared aggregation (hollow diamond) or even a simple association (no diamond) would also perfectly match this definition, keeping in mind that UML does not define the semantics of shared aggregation.

    Composition over inheritance

    GoF are as far as I know, the first who recommended composition over inheritance. Page 20 of their pioneering work they made the following very precise statement (highlighting by me):

    Favor object composition over class inheritance

    We all like short mantras. Hence, this was quickly taken over without "object" and "class".

    Conclusion

    Whenever people speak about GoF patterns, you'll face the risk that aggregation or composition symbols might not be accurate, and that composition could have several meanings. So, you need to read it with critical thinking and an open mind. As patterns are not magical recipes, and may anyway need to be adapted to your own constraints, this state of mind can only be of advantage for you ;-)