Re: Delegates -- WHAT is delegated?
Re: Delegates -- WHAT is delegated?
- Subject: Re: Delegates -- WHAT is delegated?
- From: Uli Kusterer <email@hidden>
- Date: Wed, 20 Dec 2006 10:27:06 +0100
Am 20.12.2006 um 06:59 schrieb Sam Colombo:
Silly me, I was looking in the headers where I would expect to
find it.
A quick comparison of headers with the documentation list leads
that you
mentioned (thank you) for NSWindow and NSApplication leads me to
believe the
delegatable methods are mainly in the NSApplicationDelegate or
NSWindowDelegate protocols and the NSApplicationNotifications and
NSWindoNotifications respectively. Supposedly, notifications
automatically
get sent to delegates anyway.
In AppKit, Apple generally hand on the notifications to the
delegates, yes. And also, in general, there is a category on NSObject
(used as an informal protocol) in every class that delegates methods
that declares these methods (generally named something like
NSSomethingDelegateMethods). That's just a convention followed by the
AppKit developers internally. There's nothing in Objective C that
enforces this (though it's a good idea to do the same in your code,
even if just to reduce the surprises others have when they use your
code).
I keep reading things like "dont subclass -- delegate
instead". Then
the first examples I see, the first thing they do is start subclassing
everything like NSView. If they'd let delegates handle the events
and the
draw method instead of subclassing NSView, event handlers could be
more
modular and more easily swapped out to handle different content in
the same
view.
There's nothing keeping you from creating your own view class that
delegates things if you want to. However, one advantage of delegation
is that you can implement the delegate methods for several views in
one controller object. That's why delegation /can be/ better than
subclassing. You don't need a subclass of each view (and for example
NSTextView *does* delegate some of its tasks) just to implement
application-specific logic. You can use the standard objects
unchanged and as-is.
In C++ I often see subclasses of views that add the controller
code. If you want to change the view, you have to rewrite the
controller as a subclass of a completely different object. With
delegation, you just switch out the view, maybe add some methods to
your controller to handle calls from the new view, and you can now
even switch between the old and new views.
However, if your code seems to be in any way reusable and
conceptually fits in the view layer, you *want* it in a subclass of
the view. The controller is in general the code that's inherently
specific to this particular application, and thus there are few
controllers that are actually reusable.
For me it always helps to think of it this way: If I wouldn't have
some code in a command-line tool, or it would be significantly
rewritten, it's part of the view. If it works on my data, it's part
of the model, and if it negotiates between model and view, it's
controller logic.
I can see why subclasses are good for the specialized views
mentioned,
but where I am really going is the main view where I intend to have
a s--t
load of layers and content types that each need their own handlers
(i.e.,
controllers). I like the MVC concept, but I would like to keep the
C out of
the V.
Either the structure demands dedicated handler objects, then use
them and be happy that ObjC forces you to separate them, or just
combine them in one object (if this structurally and logically makes
sense). That's why we have this design pattern, to use objects to
group your code, not to have a second "mirror object" for each object
because they all expect the same method name.
It's perfectly OK to have additional helper objects. For content
types, you probably want to create plug-in objects anyway, and those
would take care of the type-specific work. Just like NSImage has
NSImageReps do the actual work of loading and saving an image. But if
the whole point of a view is to display a date as an editable text
field, why would you go through the lengths of adding additional
objects just to return a date? You just use a data source to give you
your data in a standard format or several, and display that.
Does that clear up your questions a little? I have to admit I do
most of this kind of "instinctively" these days, so it takes some
mental effort to try and uncover all the reasons I think of when I
refactor some code without having some code to remind me where the
spots in need of work are. After you've written and read more Cocoa
code and you're more familiar with the structure of Cocoa, you'll
just start "seeing" where a divide between objects should be. Cocoa
itself is a good example of when to delegate, when to subclass.
(well, at least the older stuff, there's some new frameworks that
seem to be a little off structurally, and we have at least three
image classes now where different representations would probably have
done the job better...)
Cheers,
-- M. Uli Kusterer
http://www.zathras.de
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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