Re: Objects cross calls
Re: Objects cross calls
- Subject: Re: Objects cross calls
- From: j o a r <email@hidden>
- Date: Mon, 23 Jan 2006 17:00:35 +0100
On 23 jan 2006, at 16.18, Lorenzo wrote:
- dealloc
{
[basket removeFruit:self];
[super dealloc];
}
IMO, this is incorrect design. First of all you have the practical
problem that this prevents the Fruit to ever be deallocated. More
important though is the concept of ownership and control.
From what I gather you have a Fruit class and a Basket class. I also
think that you have one or more Controller classes, or if you don't,
you should. The controller functionality might optionally be
integrated into the Fruit and Basket classes, but you often get a
cleaner design if you split it out into separate classes.
I would solve this problem by routing all actions via the controller.
When you want to add a Fruit to a Basket, have the controller do it.
When you want to remove a Fruit from all baskets, have the controller
do it. Much like you suggest here:
- (void)deleteFruit:(int)index
{
aFruit = [fruits objectAtIndex:index];
[[aFruit basket] removeFruit:aFruit];
[fruits removeObjectAtIndex:index];
}
You list additional problems:
This begins to be complicated if you think that some call could
remove all
the fruits or even release the fruits array like these calls
[fruits removeAllObjects];
[fruits release];
What to do in case of these 2 calls above?
What about it. I don't quite see the problem you're describing. Can
you think of a concrete example? If you funnel all mutating actions
through the controller, you should be safe, and I don't expect there
to be all that much complexity for you to deal with.
I think there should be a more efficient method than cross-
connecting the 2
objects. I though about relational database and record IDs but I am
afraid
that is not the right approach.
How would it solve the problem? You still need to keep track of the
owners of the Fruits.
Another way to solve the removal of Fruits would be to send out an
willRemove notification and let the Baskets react accordingly -
without the help of a controller. It's not much of a difference in
implementation, but some people prefere the looser connection between
objects that you get by using notifications.
What's about creating an array with simple pointers of the fruits?
Avoiding the "problem" of the Fruits being retained by the array? You
would still have to update the array when Fruits are added / removed,
so that wouldn't help at all.
j o a r
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden