• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Asyncronous message handling
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Asyncronous message handling


  • Subject: Re: Asyncronous message handling
  • From: Keary Suska <email@hidden>
  • Date: Wed, 7 Jan 2009 11:20:06 -0700


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".

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).

HTH,

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"

_______________________________________________

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


  • Follow-Ups:
    • Re: Asyncronous message handling
      • From: "Mohan Parthasarathy" <email@hidden>
References: 
 >Asyncronous message handling (From: "Mohan Parthasarathy" <email@hidden>)
 >Re: Asyncronous message handling (From: Keary Suska <email@hidden>)
 >Re: Asyncronous message handling (From: "Mohan Parthasarathy" <email@hidden>)

  • Prev by Date: Re: Automatically filling an app with test data
  • Next by Date: Re: Quartz Composer For Games?
  • Previous by thread: Re: Asyncronous message handling
  • Next by thread: Re: Asyncronous message handling
  • Index(es):
    • Date
    • Thread