CODEWITHSUNDEEP
oopumlaggregationcompositionobject-oriented-analysis
AlwaysLearning
AlwaysLearning

Reputation: 181

Aggregation vs Composition : Thinking at object level or class level

I am confused about how to decide aggregation vs composition for Has-A relation. Let me explain my doubt with example of BookMyShow App(BMS) which is Show booking platform and assume a Show can be booked for a Movie, Standup comedy or any such event.

Now let's say for some usecase we have this relationship in our code, i.e. a Movie has list of Shows.

Object level thinking: A Movie object has a list of show objects, if I delete this movie object due to any reason, all these show objects will make no sense as they were corresponding to that movie, so this relationship is Composition.

Class level thinking: Movie class has list of Show, if I delete Movie class from my app, will there be no use of Show class? No, because we have other events as well which will have Show class, so this way Show class can exist even without Movie class, this way Movie has shows is Aggregation relation.

Now my questions:

  1. Which way of thinking is correct out of the two?
  2. Am I wrong in any of the above ways somewhere and due to which the end result of type of relationship is different? Am I missing something in any approach?

Upvotes: 2

Views: 134

Answers (1)

Christophe
Christophe

Reputation: 73530

When you look at associations or composite aggregation, it's all about how instances (objects) of each class could be linked and related. But the association is then expressed for the class.

Let's take the example: imagine a Movie "XYZ", for which there's a Show on 2024-07-11 at 17:00 in Los Angeles, and another one on 2024-07-13 at 20:00 in Pasadena. So the specific movie instance is linked to two show instances. More generally, this means that there is an association between the two classes.

Moreover, if none of these shows should survive the death of this specific movie, and if this turns to be true for all other shows and movies, you could chose to consider a composite aggregation at the class level. However, you could also think in the shooes of a theatre manager: if I have some shows planned for a movie the movie is destroyed, I could decide to keep the shows and link each one with a different but similar movie. In this case, the composite aggregation would not be justified.

Last but not least, the movie "XYZ" was linked to two shows. But another movie "WWW" could be linked to no show yet, and still another movie, "The good, the bad and the ugly" could be linked to thousands of shows around the globe. Inversely, each show would be linked to exactly one movie. So the multiplicity at the show end would be 0..* and at the movie end it would be 1. So the possible cardinalities at the instance level define the multiplicity (lower and uppeer bound) at class level.

In conclusion the associations are defined at class level, but specify possible links at instance level. The class is a placeholder for possible instances that share some common features.

One more thing: you should not see the association as a list. Associations are potentially bidirectional, some are navigable only unidirectionally. Lists are only a mean to implement certain kind of association. Sometimes, a reference is sufficient (for 0..1 multiplicity). Sometimes two lists are necessary to navigate in both directions. But sometimes, there is no list, at all. For example an independent dictionary can implement the association. Or in an RDBMS, a join condition can implement the association.

Upvotes: 1

Related Questions