In computer science, we have no shortage of ambiguous terms. You have probably seen colleagues arguing at the coffee machine, getting more and more frustrated, only to discover they are either saying the exact same thing or talking about completely different things.
Composition is one of those perfect examples.
Let me ask you a simple question. What is composition?
You might answer: object A has an instance of object B. Or: object A determines the lifecycle of object B. Both answers are correct because the word composition is used for two different but related ideas.
On one hand, there is technical composition. On the other hand, there is conceptual composition as defined by UML.
To understand the difference, we need to take a small step back and look at relationships in UML.
The weakest relationship is a dependency. Object A knows object B. For example, a method in A takes a parameter of type B. To make that work, class A needs to import B. Class A depends on class B.
A step stronger is association. Class A still knows class B, and now it also stores a reference to it. Think of constructor injection. Object A receives B and assigns it to a field.
Now here is where things get confusing.
From a technical point of view, this is composition. Object A is composed of its own fields plus object B. The code does not care how B got there or who created it. But UML does care.
In UML, association does not say anything about ownership or lifecycle. If object B was created somewhere else, for example in main, and main still has a reference to it, then destroying A does not destroy B. Object B can outlive object A so it can be passed around to other objects.
This form of association is called aggregation in UML.
UML composition is also a form of association but even stricter. In UML composition, object A creates object B and owns it. B only exists because A exists. When A is destroyed, B is destroyed as well. A good example is an HTML document.
A web server creates an HTML tag. That HTML tag creates body tags and other sub tags. Those child tags make no sense on their own. Destroy the HTML tag and everything inside it disappears. And that is what UML calls composition.
Technical composition simply says: object A has object B. It says nothing about ownership or lifecycle.
UML composition is conceptual. It says: object A creates and owns B, and controls its lifetime.
Same word. Different meanings.
And once you understand that, the coffee machine arguments tend to end a lot faster.
Written by Loek van den Ouweland on Dec. 17, 2025.