Re: aggregation and states



Date view Thread view Subject view Author view Attachment view

From: Ulf Schuenemann (ulf@cs.mun.ca)
Date: Mon 10 Jun 2002 - 23:45:57 BST


Gonzalo wrote:
> "Composite aggregation is a strong form of aggregation, which requires that
> a part instance be included in at most one composite at a time and that the
> composite object has sole responsibility for the disposition of its parts.
> [...]"
>
> This seems to me rather ambiguous.

Agreed. "Responsibility for disposition" leaves me wondering...
Is this a responsibility to list on the CRC card for class Car? - Is
this responsitibility "required" *before* we can use composition
between Car and Wheel, or does composition *imply* responsibility by
virtue of the postulated requirement of a responsibility?

I doubt that "sole responsibility" means that only the composite
object can make the constructor call which creates its components.
If so, you could not use the Abstract Factory pattern any more and
other examples of flexible object creation where the decision which
object to instantiate is separated from the object(s) using it (eg. as
a component). The Car object should be able to *delegate* creation
of (some of) its parts to other objects (factories). [sidenote: also
inner objects in COM do not need to be created by the outer object]


> As far as a wheel belongs to a car, nobody can "touch" it.

How do you mean this? In the real world, the road touch the wheel. Are
you refering to some notion of encapsulation in the software model?

> In my opinion, this is the root that the "sole responsibility" has no
> practical effects, it means nothing in practice.

That's my conclusion too, but I don't see this as negative.
Why shouldn't some instances of classes Light, Radio, or Seat be
components of a Car, while other instances of the same classes are
not? Or to take a more low level example: You realize high level
Set objects as composite objects with BinNode objects as components
that are organized in a balanced binary tree structure. Why should it
not be possible to use other BinNode instances (to reuse class
BinNode) for tree structures that are not internal to a composite
object?

Or should such situations be modeled using aggregation ???
I prefer the modeling language to be flexible. If classes Engine,
Seat, etc., are intended to model _car_engines, _car_seats etc, this
can still be expressed by writing cardinality 1 to the composition
association. [Cardinalities cannot express that instances of, eg.
Engine/Motor, must always be component of 'some' larger composite, be
it Car, Ship, Elevator, RotaryPress, ... but is this an interesting
property to model?]


My $.02, to be continued ...

Ulf

Date view Thread view Subject view Author view Attachment view