Re: Aggregation vs composition
From: Daniel T. (postmaster_at_eathlink.net)
Date: 05/09/04
- Next message: Daniel T.: "Re: Aggregation vs composition"
- Previous message: Isaac Gouy: "Re: Why is OO Popular?"
- In reply to: Matthias Hofmann: "Re: Aggregation vs composition"
- Next in thread: Matthias Hofmann: "Re: Aggregation vs composition"
- Reply: Matthias Hofmann: "Re: Aggregation vs composition"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 08 May 2004 22:55:54 GMT
"Matthias Hofmann" <hofmann@anvil-soft.com> wrote:
> Daniel T. <postmaster@eathlink.net> schrieb:
> > Once again you are exposing a problem that *only* exists in C++. I don't
> > mind using code for examples, in fact I prefer it, but please don't harp
> > on problems specific to the language of the example...
>
> Why shouldn't the UML give a possibility to show these problems in a
> diagram?
Every programming language has it quirks that are specific to that
particular language, new languages are being created all the time. I
don't believe it is appropriate for a notation system to have special
notations specific to each language. If Composition is simply a special
notation that only has meaning in C++, then maybe it would be better if
it were either removed, or given a more general definition.
>
> > >
> > > The way I see things, it is the client of the container who is limited
> > > as to
> > > how it can use the part. Unless you are arguing that the container
> > > cannot
> > > change its behavior because it cannot update the documentation any
> > > more. I
> > > have , of course, assumed that changes in the implementation and/or
> > > behavior of the whole lead to an update of the documentation, possibly
> > > breaking old client code.
> >
> > Of course. The documentation, once laid down, limits *both* participants.
>
> I agree with that. And if the documentation shows that a composite whole is
> responsible for the disposition of the parts, why shouldn't a UML diagram
> demonstrate the same thing?
The documentation cannot grant the whole sole responsibility while also
putting limits on the whole vis-a-vis the disposition of its parts.
> > It doesn't really matter who places the limits, the fact still remains
> > that limits have been placed. All objects sharing the part must abide by
> > those limits, they are all responsible for the object's disposition.
>
> Why can't I model these limits in a UML diagram, using a composition
> relationship? I think the documentation and the diagram are closely related
> to each other.
They are supposed to be yes. But what if you saw this in the diagram:
[A]--->[B]
Then in the documentation you read "A objects never send messages or
otherwise know about B objects"
What if you saw:
[A]<#>--->[B]
Then in the documentation you read "A is not solely responsible for the
disposition of the B objects it holds."
Wouldn't you complain?
> > It almost sounds like you are actually arguing that [B]<---[C] means
> > that C is not allowed to keep a reference to B past the lifetime of its
> > method calls...
>
> You mean, past the lifetime of B's member functions? Yes, if an object is
> gone, you cannot call a function on it of course - or what exactly do you
> mean?
I mean, if given the following diagram:
[A]<#>--->[B]<---[C]
Would you consider the following code correct?
class A:
def __init__(self):
self.b = B()
class C:
def setB(self, b):
self.b = b
a = A()
c = C()
c.setB(a.b)
IE: Is it appropriate for both 'a' and 'c' to hold a reference to 'b'
for an indeterminate period of time, or should there be definite limits
on their ability to hold on to the 'b'?
- Next message: Daniel T.: "Re: Aggregation vs composition"
- Previous message: Isaac Gouy: "Re: Why is OO Popular?"
- In reply to: Matthias Hofmann: "Re: Aggregation vs composition"
- Next in thread: Matthias Hofmann: "Re: Aggregation vs composition"
- Reply: Matthias Hofmann: "Re: Aggregation vs composition"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
