On Jul 24, 2008, at 4:10 AM, Oleg Krupnov wrote:
Notifications is another point of confusion for me. I would assume
that notifications should be used when multiple observers can be
connected to an "event" exposed by an object, in contrast to a
simple
"delegate" outlet, which can only have one connected object. Am I
correct?
They're really for two different things. Often a delegate interface
supports a superset of what notifications will notify observers of;
for
example, see the descriptions of the delegates for NSWindow and
NSApplication, and compare them with those classes' notifications.
Yes, I see that delegate methods and notifications do overlap a lot.
What is this your example supposed to mean? Is my understanding of
notifications vs delegates correct or not?
It means that whether you use a notification or a delegate depends on
the level of integration with the view that you want whatever reacts
to it to have. There may be things that you tell notification
observers about and things that you tell delegates about
independently. And there may also be things delegates will need to
react to that are also available via notifications, but that you
support delegate methods for for convenience (so your delegate doesn't
need to register for notifications too).
By the way, what is the best practice of implementing delegates -
should these be separate objects or the window controller should be
the delegate? The latter approach yields fewer classes and fewer
relations between classes but, I am afraid, delegate methods from
different views in a single window controller may overlap and also
delegate message names, while meaningful in the sender views, may not
be as meaningful in the window controller, because it is an object one
level up in the view hierarchy.
Sometimes you'll want an object to be the delegate for several
objects, sometimes you'll want an intermediate controller object to
act as one of their delegates.
For example, before Cocoa bindings, I often used a TableController
class that I'd created to act as both the data source and delegate of
an NSTableView. (It was very similar to bindings in a lot of ways.)
So I'd almost never use my window controller as a table view's data
source or delegate. On the other hand, I'd still generally use my
window controller as my window's delegate.
Also, if you follow the Cocoa naming conventions for your delegate
messages, their names shouldn't overlap: A delegate is always passed
the object delegating to it as a parameter. (Example: -
numberOfRowsInTableView:.)
In general, I'll create independent objects to act as delegates when
(1) the independent object can be made generic, as with my
TableController, or (2) the delegate logic is both complex enough and
isolated enough that I don't want to clutter another controller class
with it, and can abstract it into a higher-level interface the other
controller can interact with.
The latter is also sort of what my TableController did -- it managed
an NSTableView whose columns' identifiers were key paths, and the
TableController itself had "source" and "keyPath" properties that it
used to locate the array of objects to display. So it was (1) generic
to any table view, and (2) provided a much-simplified API for most of
my applications using it over the NSTableView API.
-- Chris
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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]
