Re: Accessor methods and (auto)release: Relationships vs References in ULM
Re: Accessor methods and (auto)release: Relationships vs References in ULM
- Subject: Re: Accessor methods and (auto)release: Relationships vs References in ULM
- From: Sylvain LEROUX <email@hidden>
- Date: Wed, 7 Aug 2002 10:59:50 +0200
>
> Hi list,
>
> "Attributes" are other objects owned by an object. "Relationships"
>
> are other objects referenced by an object.
>
>
In UML is this the distinction of whether the diamond in the "has a"
>
relationship is outlined or solid?
>
As you know, both kind of diamonds in UML are the "has a" relationship.
Let's me introduce the pattern:
[ A ]<>----[ B ]
Case 1:
[ A ]<_>----[ B ]
If the diamond the pattern is outlined, this means that A has a B in the
sense that "A has a relation to B and as long as an instance of A will
live an instance of B will exists". In other word B is not necessary a
part of A. Note that, the instance of B is not necessary the same
throught the all life of the instance of A. For objects, this is the
only kind of "has a" relation possible with Objective-C. This is an
"aggregation" (or sometimes refered as "weak" aggregation).
Case 2:
[ A ]<X>----[ B ]
If the diamond in this pattern is a solid one, this is a special case of
aggregation witch means: "A has a relation to B and as long as an
instance of A will live an instance of B will exists"(like in case 1)
but also (that's the point): "B is a part of A". Since Objective-C does
not allow static objects, this is not really possible in Cocoa. This is
called a "composition" (or sometimes refered as "strong" aggregation).
Notice that in both case, the container object (i.e.: the instance of
class A) is responsible for releasing this contained object (i.e.: the
instance of class B); According to your programming langage and the kind
of aggregation, this may be done by the compiler or by the programmer...
Notice too, that since in the case of composition, B is "inside" of A, a
given instance of B can only be the part of *only one* instance of A.
In the other hand, in the case of weak aggregation, a given instance of
B can "belongs" to several differents instance of A. So there must be
some kind of mechanism to ensure that the instance of B will survive as
long as an instance of A possessing it exists. That's exactly the
purpose of the "retain/release" sheme implemented in Cocoa!
Notice finaly that, in the case of weak aggregation if an instance of A
(say a) has an instance of B (say b), 'b' *cannot* have 'a' as an
aggregation, since this will result of 'a' living at least as long as
'b' and 'b' living at least as long as 'a': that's the "retain cycle"
you may find in Cocoa's documentaion, witch cause both memory leaks and
objects never being deallocated.
(-*-*-)
As a more precise answer to your question, with the definition:
>
> "Attributes" are other objects owned by an object. "Relationships"
are other >> objects referenced by an object.
"Attributes" are implemented by "weak" aggregation for objects:
[A]<_>-----[B]
Each instance of A has an attribute of type B.
"Attributes" are implemented by compostion for scalars (int, double,
etc):
[A]<X>-----[double]
"Relationships" are ... relationships
[A]---------[B] (No diamonds at all here!)
At some point of it's existance, an instance of A knows an instance
of B.
Here the key difference is the life time of objects involved in this
relation: The fact the an instance of A no longer exists does not have
consequence on the existence of the instance of B. The opposite is also
true: An instance of B may terminate it's life, when in the same time
the instance of A in relation with it continue to live. Moreover, the
relation itself may be broken at some point in time, with no consequence
for the life time of instance of A and of B involved. Of course, in
order to avoid objects referencing other objects no longer existing (and
so to avoid crash:-), here again some sort of mechamism should be
implemented to allow objects knowing when other objects in relation with
them are no longer valid (or no longer wants to be involved in such a
relation). In Cocoa, that what does (for example),
addObserver/removeObservers.
I hope I clear enougth...
(-*-*-)
Oh, by the way, just to add my stone at this 'Accessor methods and
(auto)release' thread:
Maybe the problem of accessor returning objects which are not valid when
used (I mean: object no longer existing like it may append in the case
of 'retain-endian', or object having a wrong value like it may append in
the case of 'autorelease-endian') is caused by the lack of support from
Objective-C the language for cv-qualifier 'const' like in C++.
For example, I never had problems with accessors like that
class A
{
public:
...
inline const B& b(void) { return _b; } const;
private:
....
};
...
A myA;
const B& itsB = myA.b();
Because *I know* that the returned reference will *stay valid* at least
as long as I call only 'const' methods on 'myA'.
In the other hand, if I call an non-const method of myA, *I know* that
the state of myA *may* change, so 'itsB' may be invalid (no longer
existing, or wrong value).
(I'm not sure that helps a lot...:-)
Bye,
Sylvain
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.