Re: Design Question: Pro & Cons of KVC/KVO
Re: Design Question: Pro & Cons of KVC/KVO
- Subject: Re: Design Question: Pro & Cons of KVC/KVO
- From: "Kyle Sluder" <email@hidden>
- Date: Thu, 21 Aug 2008 23:59:55 -0400
On Thu, Aug 21, 2008 at 10:27 PM, Graham Cox <email@hidden> wrote:
> But one thing that has been overlooked - common or garden notifications. If
> all you want is to pick up a change in an object a notification is a simple
> way to do it without writing your own messaging system. It's less powerful
> than KVO but simpler to understand and much less fussy about managing its
> "connections" than KVO. Think of it as a half-way house between doing it all
> yourself and using KVO, which might seem to be "too much magic" for some.
I don't think using notifications for communication between specific
objects is the best idea. I tend to think of notifications for
broadcasting state changes that any other object may be interested in.
For example, say I have a window with a toolbar and an NSSplitView.
It wouldn't make sense to use the delegation pattern between my split
view and my toolbar. So that leaves me with two options,
architecturally:
1) Create a C#-style event handler list. In C# (and other .NET
languages, but C#'s syntax is easiest), objects declare that they have
events. So a SplitView class in C# might have an event called Resize:
delegate void ResizeDelegate(object sender, EventArgs e)
class SplitView
{
public event ResizeDelegate Resize;
}
Then, somewhere I would wire my toolbar up to that event:
class Toolbar
{
public Toolbar()
{
// Make the SplitView notify us if it resizes
theSplitView.Resize += new ResizeDelegate(this.toolbar_Resized);
}
private toolbar_Resized(object sender, EventArgs e)
{
// Typical example: change the text on a "show/hide side pane" button
}
}
This approach is very in keeping with C#'s static typing; the events
an object can raise are well-defined members of the class. The
downside, though, is that somehow your client objects need to know
about all the objects that they want to attach themselves to. Your
object graph gets very, very dense if you have more than a few of
these sorts of events.
2) Broadcast notifications to anyone who may be interested.
@implementation SplitView
{
-(void) setSize:(NSSize)newSize
{
[[[NSNotificationCenter] defaultCenter]
postNotificationName:SplitViewResized object:self];
}
}
@end
Now my client objects can specifically listen for this message coming
from this SplitView, or they can listen for all messages, or just this
message from any SplitView.
@implementation ToolBar
{
-(id) init
{
[[[NSNotificationCenter] defaultCenter] addObserver:self
selector:@selector(splitViewResized:) object:mySplitView];
}
}
Much more flexible, but at the cost of knowing what messages the split
view might throw, and it loses the static typechecking that the C#
delegate approach affords; the C# event is typed as only taking
methods which return void and accept an object and an EventArgs, while
the Cocoa method will fail at runtime if ToolBar doesn't implement
-splitViewResized:.
The real power of notifications comes when you have, say, a hundred of
something. You want some UI element to know when any of your hundred
things enters state X (a collision, for example). With .NET events,
you have to register this object with each of your target objects. In
Cocoa, your objects just scream out and the client hears them.
--Kyle Sluder
_______________________________________________
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