Re: delegation of NSApp
Re: delegation of NSApp
- Subject: Re: delegation of NSApp
- From: Matthew Formica <email@hidden>
- Date: Wed, 05 Sep 2001 16:13:43 -0700
In general,
- delegates are typically for 1-to-1 relationships; you give an object a
delegate in most of the cases where in other frameworks/languages you would
need to subclass. Delegates get a fair amount of control over the behavior
of the object that delegates to them.
- notifications are typically for one-to-many relationships; a bunch of
objects (observers) sign up to be notified when some event happens.
Observers typically have little control over the behavior of the notifying
object - they just want to find out that something has happened so they can
take their own actions, not make decisions on behalf of the notifier.
Usually in small apps, you tend to merge different roles into a few classes
for simplicity. Your main app controller class can probably handle the
delegations just fine.
Hope that helps.
Matthew Formica
Apple DTS Engineer - Dev Tools and Cocoa
email@hidden
on 9/5/01 3:45 PM, Robert Goldsmith at email@hidden
remarked:
>
Hi :)
>
>
As I mentioned earlier, I'm getting my head around the idea of delegation.
>
>
When you wish to respond to notifications such as
>
applicationWillTerminate, I figure there are two ways to go - either
>
register as being interested in tht notification with the
>
notification center or delegate NSApp. Which is 'better' and why.
>
Also, if you delegate NSApp and you only have a small program, is it
>
better to have a second class to deal with the delegations (and does
>
this have to be instantiated in the nib) or incorportate the
>
delegated notification responses into the main application class
>
instance.
>
>
Or have I missed something?
>
>
Thanks
>
>
Robert