Re: Delegates - I give up
Re: Delegates - I give up
- Subject: Re: Delegates - I give up
- From: Alastair Houghton <email@hidden>
- Date: Mon, 21 Jan 2008 12:06:24 +0000
On 21 Jan 2008, at 10:53, William Squires wrote:
Okay, I'm beginning to think the whole "delegate" system needs some
help. Namely, they don't seem to be self-documenting. In REALbasic,
if one wants to know what a "control" can do, examine its events in
the code editor window. You can then put code there to handle that
event.
I'm not sure that I see exactly what you're saying here. How would a
delegate be "self-documenting" in your opinion?
But with delegates, how do you find out (easily) what delegates a
control has, short of going to XCode help/documentation?
You could look at the header files. Delegate methods are generally
declared as a category on NSObject, e.g.
@interface NSObject (MyDelegateMethods)
- (BOOL)shouldSendEmail;
@end
I don't see what's wrong with looking at the docs though.
And, more to the point, where to put the delegate methods?
I think perhaps that you need to spend more time familiarising
yourself with the fundamentals here.
An object's delegate is merely another object that implements
functionality on its behalf. It's a standard OO pattern (if you're
interested in such things) and isn't anything specifically to do with
Cocoa, though the Cocoa frameworks make more extensive use of
delegation than many others that I've seen.
Anyway, you put the delegate methods on the object that you have set
up (either in IB or via code) as the delegate of the object that you
want to implement delegate methods for.
Is there a better paradigm for thinking about controls/delegates? If
so, please clue me in!
In many frameworks, you would have to subclass an object to change its
behaviour. But sometimes there is behaviour that you are *obviously*
going to want to customize under many circumstances, and in that case
it's wasteful and over-complicated to require you to subclass
something just to e.g. change under what circumstances your
application will allow the user to exit. As a result, Cocoa uses the
delegation pattern (which, as I said, is a standard OO design
pattern), which means that an object may provide the ability to ask
some other object for help under specific circumstances. e.g.
NSApplication can ask its delegate whether the application should
terminate now.
Cocoa objects generally have a single "delegate" outlet, and usually
delegate methods will be optional, since it's all about customising
the behaviour of the original object without subclassing. Usually the
delegate will be a controller object of some sort, and it may be the
delegate for multiple objects.
And, for that matter, what's the difference between a delegate and
an action? (besides the fact that you can connect actions in IB)
An action is a particular message (method). The question you were
perhaps trying to ask is "what's the difference between a delegate and
a *target*?"
The answer is that the target of a control is sent the action message
when that control is used (the exact circumstances vary from control
to control). The *delegate*, on the other hand, may be sent a variety
of messages by the object(s) it is acting on behalf of, for all sorts
of purposes; mostly, delegate messages are about customizing the
behaviour of another object, whereas target-action messages are about
responding to input from the user. Other frameworks often muddle the
two up, which I suspect is one reason for your confusion.
Kind regards,
Alastair.
--
http://alastairs-place.net
_______________________________________________
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