On Wed, Jan 7, 2009 at 10:20 AM, Keary Suska <[email protected]>wrote:
> > On Jan 7, 2009, at 10:44 AM, Mohan Parthasarathy wrote: > > NSNotificationCenter? Object Delegation Pattern < >> http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CommunicatingWithObjects/chapter_6_section_4.html#//apple_ref/doc/uid/TP40002974-CH7-SW26> >> ? Key-Value Observation? >> Thanks for your response. I did look at Delegation but perhaps confused >> because i thought object A also has to know about object B which i guess is >> not needed. Is the following right understanding ? >> >> object A has a method: -(void)fetchData:(id)sender >> and also looks for a delegate in object B: >> [sender respondsToSelector:@DataReady] >> >> object B sends a message to object A: fetchData:(id)self >> and implements DataReady >> >> This way object A need not know anything about object B i guess. >> >> Isn't Notification mechanism used for one-to-many ? >> > > > The main pitfall to avoid is a retain cycle. In delegation, objects don't > typically retain their delegates, so you avoid the cycle problem. Delegation > is often implemented with a protocol, so the objects aren't too tightly > bound. I.e., the protocol defines the method calls, so you don't need to > know anything about the delegate, other than it must adopt the protocol in > some way. Also refer to the URL above with conventions that allow a delegate > to support multiple "delegators". So, before making the call to object A, i have to retain the delegate object. In my use case, the delegate object is the viewController. I am not sure whether there are any caveats with respect to retaining this. At least, i can't be sure that this viewController will be the active one and i hope there is some way to check that. > Regarding notifications, they simply allow messages to pass between objects > that aren't related at all--i.e. neither objects has to know anything about > how to send messages to the other. This allows for a more flexible > interaction, but is less efficient than delegation. You can also run into > strange crashes with nested notifications, I have found, but I find > notifications very useful in many circumstances. > > Certainly, delegation is "many-to-one" only in the sense that a delegate > can be a delegate for many objects but an object can only have one delegate, > and notifications get around this issue. I would really call notifications > "many-to-many", since notifications don't have to be specific to certain > object or class. But there is nothing wrong, IMHO, with only one object ever > listening for a specific notification (one-to-one). Thanks for the clarification. -mohan > > > HTH, > > Keary Suska > Esoteritech, Inc. > "Demystifying technology for your home or business" > > _______________________________________________ Cocoa-dev mailing list ([email protected]) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
