3

When a class holds a type of another class as an attribute, what kind of relationship is this - association or aggregation?

e.g.

a Flight class holding a type of City class as an attribute called Destination - is this an association or aggregation? What would be the name of their relationship in either case? Flight- "arriving" -City?

Another scenario:

A FlightBooking class holding a type of BusinessClass class as an attribute to show that it is a business class flightbooking - is this association or aggregation?

Thanks!

Nifle
  • 11,745
  • 10
  • 75
  • 100
Roger2233
  • 231
  • 1
  • 2
  • 3
  • @marcin, maybe the OP is trying to learn so that he has a vocabulary which he can use to communicate common ideas with others. Why else learn the correct words for things? – Sam Holder May 22 '11 at 20:06
  • @Sam Holder: It sounds like homework to me. I also find it odd that one would care about the name when the semantics are clear. Last of all, I think UML discourages good design. – Marcin May 22 '11 at 20:26
  • @Marcin: UML discourages good design? Perhaps you could elaborate? – sfinnie May 22 '11 at 21:44
  • 1
    @sfinnie: UML encourages a focus on the data model (good in many ways), but it almost totally obscures the role of methods. You can represent java-style interfaces, but it doesn't tell you much. The representation of constraints and assumptions about the methods are doing is also cumbersome. – Marcin May 22 '11 at 22:48
  • @Marcin: thx for reply. One could equally argue that mainstream programming languages 'discourage good design' due to lack of good support for relationships. Point is UML, like all the other tools in our armoury, is not universally good or bad. It has strengths and weaknesses. Making blanket statements doesn't really help - especially in the context of a beginner's question. Your subsequent response clarifies your point though so makes it more useful. – sfinnie May 23 '11 at 07:55
  • @sfinnie: In what sense do programming languages lack support for relationships? – Marcin May 23 '11 at 08:12
  • @Marcin: relationships aren't 1st class constructs in prog languages. Instead, one has to deconstruct relationships into pointers/collection classes. Understanding the relationship is therefore an exercise in 'reverse engineering' the relationship properties back out of the code (multiplicity, optionality, create/delete responsibility, business rules/constraints the rel represents). – sfinnie May 23 '11 at 08:38
  • @sfinnie: I don't know what you mean by "deconstruct". Just because they are not called relatinships does not mean that they are not reified representations of relationships. If you want first-class objects, then you can just create them - there is no need for your language to provide special support. The reason people don't do this is that they don't find it valuable, because implementing the data model in code is not the problem. Designing and modelling the dynamic aspect is. – Marcin May 23 '11 at 10:09
  • @Marcin: 'deconstruct' = take a relationship and split into two parts, one in each participating class. And relationships aren't just static things, they capture dynamic too. Not as simple as "just creating" objects. That's like saying you can do polymorphic types in C: yes it's possible but involves a significant overhead without language support. – sfinnie May 23 '11 at 10:23
  • @sfinnie: I don't see how this discourages good design - after all the code that captures these relationships isn't that hard to write, and the support now with test-driven-development tools is pretty decent. – Marcin May 23 '11 at 10:55
  • @Marcin: with respect, you're straying from the point. You made a blanket statement that "UML discourages good design". When asked, you clarified that as UML provides poor support for methods (with an implicit comparison to programming languages). My point was (is) that UML is a tool like any other to wield as and where we see fit. I used UML's support for relationships as a relative strength - a position you seemed to agree with in your comment "UML encourages a focus on the data model (good in many ways)". But the point is not about relationships or methods. It's whether ... – sfinnie May 23 '11 at 11:33
  • (ctd)...blanket statements like "language X or tool Y discourages good design" are helpful. Particularly in the context of a beginner's question. I'd argue not. Your explanation behind the assertion is much more valuable. We could continue a debate on the relative merits of relationship support, but we're probably straying too far off topic for this question. Suggest we leave there (and hope the dialogue is useful to OP!). – sfinnie May 23 '11 at 11:36
  • 1
    possible duplicate of [UML association vs. composition and detail level](http://stackoverflow.com/questions/6086718/uml-association-vs-composition-and-detail-level) – Rick Smith Aug 24 '15 at 15:27

2 Answers2

4

A Flight class holding a type of City class as an attribute called Destination - is this an association or aggregation?

That depends on what kind of behaviour you want to get in your program, but in most cases, it should be an association. When you delete the Flight object (in memory, in your database etc.), you don't want the destination City data to be deleted too, or do you? As a general rule of thumb: use an aggregation of B in A whenever you want the lifetime of A and B to be the same; use an association whenever the lifetime should be decoupled.

Doc Brown
  • 19,739
  • 7
  • 52
  • 88
0

Think of the terminology - association is much more general-sounding. It makes sense to say that for "a Flight class holding a type of City class as an attribute called Destination" - that this is an association.

Caffeinated
  • 11,982
  • 40
  • 122
  • 216