Re: Aggregation vs composition

From: Michael Rauscher (michlmann_at_gmx.de)
Date: 05/24/04

  • Next message: Hugo Kornelis: "Re: Nearest Common Ancestor Report (XDb1's $1000 Challenge)" 
    Date: Mon, 24 May 2004 01:52:16 +0200

    Hi Daniel,

    Daniel T. schrieb:
    > In article <c8qr58$rpb$1@news1.nefonline.de>,
    > "Matthias Hofmann" <hofmann@anvil-soft.com> wrote:
    >
    >
    >>Daniel T. <postmaster@eathlink.net> schrieb in im Newsbeitrag:
    >>postmaster-41002B.22471722052004@news5.west.earthlink.net...
    >>
    >>>Again, I'm left with the feeling that no client of A should be allowed
    >>>to send a message directly to its 'b' object without A having a chance
    >>>to intercept, and possibly reinterpret that message.
    >>
    >>Then simply don't design your code in such a way. Others have already said
    >>that the UML does not prevent you from bad design.
    >
    >
    > By this comment, are you saying that allowing others to share the part
    > is "bad design"?

    Well, I'd say it's bad design, if one doesn't hide information when he
    would be able to.

    >
    >
    >
    >>>No, my answer is that after the addition of that one method, CarClient's
    >>>responsibility for engine is exactly the same as Car's responsibility
    >>>for that very same engine object. Both must make sure their use of the
    >>>engine does not conflict with the other's use of that same engine,
    >>
    >>This point has nothing to do with the responsibility for the disposition of
    >>the engine.
    >
    >
    > Obviously I don't agree. Being solely responsible for ones disposition
    > includes responsibility for their attitude...

    That's your interpretation of "being solely responsible". UML's
    specification gives this term a more precise meaning: "that means that
    the whole is responsible for creation and destruction of the parts. In
    implementation terms, it is responsible for their memory allocation".
    Within this refinement the terms "sole" or "solely" don't appear.

    Does CarClient allocate memory for Car's Engine? No.
    Does CarClient free the memory for Car's Engine? No.
    Is there any other class that allocates/frees memory for Engines? No.

    Now I ask you, if there isn't any other object but the Car instance that
      allocates/frees memory, then which object should be responsible for
    memory allocation if not the Car instance?

    Even if CarClient asks the Car to remove the engine, it is the Car
    instance that is responsible for removing it and therefore it is the Car
    instance that is responsible to free the memory.

    BTW: The same applies, if we rely on "creation and destruction of the
    parts" instead of "memory allocation".

    >
    >
    >
    >>>both must ensure that the engine's lifetime is sufficient for the other,
    >>
    >>In your own words, you are simply holding this point self-evident, which I
    >>find to be not a very convincing argument.
    >
    >
    > Surely you must agree that if either client calls delete on the engine
    > at an inappropriate time, that would be the responsibility of the client
    > that did so?

    Right and therefore such client would violate the semantics of composition.

    >
    >
    >
    >>>and both must ensure that Car is the last object to see the engine alive.
    >>
    >>As Car destroys Engine, it will definitely be the last one to see it alive.
    >
    >
    > First, you don't know that Car destroys Engine, all that is known is
    > that car is calling 'delete' on engine which may, or may not deallocate
    > the memory. Second Car cannot call delete on Engine unless it knows that
    > CarClient is done using it, to do otherwise would be irresponsible.

    Ad "First": And? AFAIK it's delete's intension to destroy objects.

    Ad "Second": This has nothing to do with composition. I'd say that in
    one should never (at least with respect to software development) destroy
    objects that are "in use" - regardless of the association type. But:
    neither association type prevents one from deleting used objects.

    Of course, you may hide parts (so part objects are used only by the
    whole) and therefore prevent the programmer technically from deleting
    used objects - because there aren't used but by the whole. But this is a
    design issue and has nothing to do with composition:

    Compare (Organization doesn't hide departments)

    [Organization]<#>-----[Deparment]<-------[Person]

    with (Organization completely hides departments)

    [Organization]<#>-----[Deparment]
          /|\
           |
        [Person]

    Problem: The latter diagram doesn't show that a person works in a
    department. Now, you could add an identifier to both, Deparment and Person:

    +-----------+
    | Person |
    +-----------+
    |-depId:int |
    +-----------+

    Now, Organization can hide Department. Organization can destroy
    Department at any time - even in GC languages :-)

    But: Person holds a "reference" to Deparment, although there is no
    association between them.

    Would you now say, that
    a) Organization should delete Deparments even if there are Persons that
    hold references on the latter?
    b) the composition prevents from deleting Deparments that Persons are
    pointing to?

    Or would you now say, that it isn't a composition because Person *knows*
    about the existence of departments?

    Bye
    Michael

  • Next message: Hugo Kornelis: "Re: Nearest Common Ancestor Report (XDb1's $1000 Challenge)"

    Relevant Pages

    • Re: Aggregation vs composition
      ... Yes, the Car cannot delete it, if you like that better. ... The only possible way for the engine to be deleted once ... Composition does not forbid sharing, as long as the part is not shared by ... Well, if that doesn't indicate sole responsibility, what else does? ...
      (comp.object)
    • Re: Aggregation vs composition
      ... > confusing holding a reference with calling delete on a reference. ... It is still Car who is responsible, ... The only possible way for the engine to be deleted once ... responsibility. ...
      (comp.object)
    • Re: Aggregation vs composition
      ... First let me bring back the Car example: ... > class Car { ... > You insist that Car is solely responsible for Engine. ... responsibility for the part. ...
      (comp.object)
    • Re: Aggregation vs composition
      ... it doesn't say that A does so without permission. ... I say that "sole responsibility" means that the whole is the ... That means that no two Car objects are allowed to hold ... >a pointer to the same Engine. ...
      (comp.object)
    • Re: Engine Check light went out by itself
      ... I think after about 5 cycles of no code, the light will shut off by itself. ... The code should still be in memory if your car is OBD II.. ... This all caues the engine check light ...
      (rec.autos.makers.mazda.miata)