Re: Appropriate dealloc and finalize actions
Re: Appropriate dealloc and finalize actions
- Subject: Re: Appropriate dealloc and finalize actions
- From: Kai Brüning <email@hidden>
- Date: Mon, 12 Oct 2009 08:30:04 +0200
Hi Karolis,
I’d say your pattern is absolutely correct. I assume those two objects
do not retain each other, they just need to know about the other one.
And they should be allowed to die separately, while cleaning up the
otherwise dangling pointer in the other object.
The good news is that GC has support for this: weak references. Simply
declare the connection ivar as weak: __weak MyClass* connection. GC
does the rest. No dealloc, no finalizer, no dangling pointer. And it’s
even thread safe.
Best
Kai
On 12.10.2009, at 04:44, Karolis Ramanauskas wrote:
If you want to do something that doesn't break encapsulation, then
you
should simply release the one ivar connection. That will let the
receiving
object perform its own actions, by itself, on its own behalf, as
appropriate
to its own affairs.
Thanks, however, I do not see how to accomplish my purpose. I'm
confused.
Help ;)
I have object1 that has a connection to object2, (object1.connection =
object2). And at the same time object2.connection = object1:
O1 -----> O2
O2 -----> O1
If one of these objects gets deallocated how should I make sure the
other
object is not pointing to the now deallocated object without doing
what I
did:
- (void)dealloc {
if (self.connection) {
self.connection.connection = nil;
}
[super dealloc];
}
Thanks
On Sun, Oct 11, 2009 at 6:11 PM, Greg Guerin <email@hidden>
wrote:
Karolis Ramanauskas wrote:
- (void)dealloc {
if (self.connection) {
self.connection.connection = nil;
}
[super dealloc];
}
Why would you do this? You're making one object responsible for the
internals of another object. This is a bad idea. It breaks the
individual
encapsulation of each object.
One of the cardinal points of good object-oriented design is that an
object's responsibilities are circumscribed. It should manage
itself and
the things it directly references, nothing else. For any objects
it DOES
reference, each of those objects also has its own responsibilities,
and so
on recursively. Objects shouldn't poke their noses into another
object's
business.
If you want to do something that doesn't break encapsulation, then
you
should simply release the one ivar connection. That will let the
receiving
object perform its own actions, by itself, on its own behalf, as
appropriate
to its own affairs.
-- GG
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden