Hello,
I’m a little confused on when exactly an association is an aggregation (white diamond).
Deciding when an association is a composition (black diamond) makes sense to me. I can ask “if the parent object is deleted, is the child also destroyed?”
However, it seems like I could argue that almost any association is a “has a” relationship.
Based on the example in the slide, if a Customer sitting at a Table is an aggregation because the table temporarily “has a” customer, even though they’re separate entities, couldn’t this logic be applied to any association?
When looking online, I found several articles like this one Aggregation And Composition , which say aggregation is largely meaningless and has no real semantics compared to composition.
Is there a straightforward rule we can follow for this course when deciding between an association and aggregation?
3 Likes
Hi,
Thank you for the question!
While I can believe that some organizations do not differentiate between associations and aggregation, for SE Lab, we aim that you learn the difference and can distinguish between them.
You are right that you can use a natural language phrasing that makes almost any relationship between two classes into a “has” relationship and, therefore, makes us think it should be an aggregation. But that misses the point the next slide (21) adds as necessary element for aggregations: There is a hierarchy between the two classes where the aggregate takes over operations from its individual parts.
In the given example, we could reason that the Table class handles the billing process (and collects the individual orders and costs for each Customer sitting at the table). Then, an aggregation is the right choice. If this hierarchy is not given in the requirements and rather describes a scenario where Customer and Table just have a simple interaction, then an regular association is correct.
I hope this helps!
Norman
2 Likes
