I understand aggregation is a "whole/part" relationship, where the "parent" class is the whole and the "child" class is the part (and this is unidirectional), and that each class exist independently (as opposed to composition). But some examples I've seen are confusing me. For instance, the path/segment relationship. I understand the segment can exist even if there is no path, but if they're independent then the path should also exist.

Same thing goes for car/wheel. I get that both objects can have independent lifecycles and a wheel can be created without being part of a car yet, but how can the car exist without weels? Some other parts of the car may exist, but it's not a complete car until it has wheels...

I've also seen triangle/line. I can draw lines and have them form a triangle or I can have just lines. But how can I have a triangle without lines?

I suspect this is because the relationship is unidirectional, but then what confuses me is the fact that both classes are independent. I understand how the child class can exist without being aggregated, but I don't understand how the parent class can have its own lifecycle without its child objects.

  • Interesting that a question being asked so many times before still gets a lot of answers at once. – qwerty_so Dec 29 '19 at 0:58

Some times an aggregation with no members makes sense... Imagine that one of the classes on your system represents a movie. And you want the system to keep the Actor credited in the movie. Does a movie without actors make sense? Yes. It could be some silent animation or other artsy stuff that manages to have no actors.

I find that a better text book example of Aggregation than the car and wheels thing which could easily descend into Theseus’s paradox (in the student mind, I mean, we put a primary key on that). Oh, and let us not forget that a wheel cannot be in two cars at the same time, however an Actor could be credited in two movies, no problem.

On the other hand, sometimes an aggregation with no members makes no sense. For that, we have Multiplicity. What are the constraints on the number of members? A Triangle must have three Lines. No more, no less. Note that Lines can still exist on their own, thus the triangle does not control the life-cycle of Lines... it is not Composition.

About the Path and Segment example. A Path without segments takes you from where you are to the same place. Whatever or not that makes sense in your system, you gotta decide. That is, the answer will be different from one system to another.

In fact, it could be different from one part of the system to another… For example, it could make sense to allow a Triangle with no Lines as a view model object, because we create it and then steadily populate it with user input over multiple interactions... while at the same time a Triangle domain model class with any number other than three Lines is not allowed… and in fact, the database entity used to store it might not have that constraint at all (saying “exactly 3” to the database engine is not easy, and could be impossible depending on the database engine).


Composition means mine! Keep your hands off.

Aggregation means look what showed up here.

Association means look what I can find.

Let's try giving these examples some actual stories.

If a car is composed of tires it means those tires belong to that car and nothing else. No sticking them on bicycles. When the car gets crushed in the junk yard the tires are going with it.

If a car has an aggregation of tires it means those tires just happen to be with the car now. They may end up on something else later or even now. The tires have an independant life of their own.

The car needs tires in either case. This isn't about the car's needs. It's about the tires.

Real world examples that try to explain the difference between composition and aggregation often fail to tell the story that makes the difference meaningful and in the end all it tells you is how the author feels about their cars tires.

For example a triangles segments might be part of other shapes while they're part of a triangle. But they might be segments that never exist for anything other than to be part of this triangle.

Examples without the stories are simply a waste of time. Stop expecting them to make sense. Tell me the story and I'll tell you which kind you have. Give me an example with no story and all you'll learn about your car tires is how I feel about mine.


Aggregation is defined by UML as a „property that has a shared semantic“ (section 9.5.3):

Indicates that the property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeller.

This is rather vague:

  • It is generally understood as a part/whole relation, with parts that can potentially be shared. This strongly suggest that the part can exist without the whole.
  • It is not fully specified, so can easily lead to misunderstandings. The best is therefore to avoid aggregation if possible. You do not need aggregation to model a part/whole relation.

The shared aggregation is different from the composite aggregation. For the latter, the UML specification is explicit, and it states that the whole (composite) has the responsibility for the existence and storage of the part (composed objects). The composed part can therefore not exist without the composite whole.

  • 1
    Interestingly OMG seems to be very reluctant to actually define those terms clearly. Even for the composite aggregation there are very different interpretations of what OMG states in their specs. This is Pandora's jar for ontologists. – qwerty_so Dec 30 '19 at 1:41

This is about how you (the developer, or a team of developers) decide to model the problem (i.e., how you decide to view and represent various elements involved based on your understanding of the problem and the relationships within).

That means that the same example can be under different circumstances modeled in two different ways (e.g. in a racing game, the player model may be considered a part of the car model, and for the purposes of that specific game, it may not have an independent existence; in a game where you are normally on foot, but can use vehicles, they are distinct entities that sometimes may assume a "containment" relationship).

So, when reading various material online, don't focus too much on the specifics of the example, but try to understand the intent, and guess at some of the assumptions made based on the context, and based on what you know about composition and aggregation.

Let's go over some of your examples:

  • The path/segment relationship: Suppose you are creating some kind of drawing software, or some sort of animation editor, or whatever. While for the user there is no path without segments (and quite possibly, no free floating segments without a path), internally, you, as the developer, may consider a path to be an abstract concept, that contains segments that can be swapped, combined and manipulated in various ways, maybe even shared in order to achieve certain special effects (I'm making this up as I go along, by the way - I'm not saying this is the-one-right-way-to-do-it). So, for you, in terms of how the software works and how things are represented, they have an independent existence. You may even do things like have a null path (with no segments) that serves as a placeholder, or an empty segment container that you'll use later, or it could simply implement the path interface (with each method doing nothing) so that your client code could be written in a simpler way. Again, the user of the software may have a completely different view of these concepts; this is about how you internally went about solving the problem of representing paths and supporting the desired behaviors - i.e., how you modeled the problem.

  • car/wheel: Again, depends on the problem domain; if you need to be able to swap wheels, or track the car & the wheels separately (I don't know, maybe the software is for a vehicle repair shop), then model that as aggregation. If it makes no sense for what you are doing to allow the wheels to exist without a car, or even if the decision to not support that is acceptable and it simplifies the problem & the code, then model it as composition.

Note two things. First, you can choose to leave the ownership details unspecified and model things using generic associations, and that is perfectly fine; use aggregation and composition when you feel that the precise relationship between two model elements is important and you want to communicate that to other developers that may be working on the same project. Second, often, all these relationships will be implemented, in terms of language features, keywords used, etc., in the same way; it's the behavior, interactions, and the lifecycle of the instances that makes the difference.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.