Re: new to Cocoa/Objective-c: many points of confusion
Re: new to Cocoa/Objective-c: many points of confusion
- Subject: Re: new to Cocoa/Objective-c: many points of confusion
- From: Jens Alfke <email@hidden>
- Date: Sun, 03 Feb 2013 18:48:11 -0800
On Jan 21, 2013, at 10:10 PM, Alex Hall <email@hidden> wrote:
> *delegates: my understanding is that these take the place of subclasses (though why this is useful is beyond me), overriding methods they are designed to handle rather than letting the base class take those methods.
They don’t take the place of subclassing; both are used in Obj-C and Cocoa frameworks. They’re different design patterns [if you weren’t exposed to the classic Design Patterns book by Gamma et al at school, run out and get a copy.] More specifically, delegation is an alternative to overriding methods. It’s more flexible in that an object can be a delegate of several other objects, even different types of objects.
Delegation also fits in well with MVC designs. It’s pretty common in Cocoa for a controller to be the delegate of a view, which lets it handle some of the less GUI-centric policy decisions of the view without getting involved in the visual details.
> However, I not only don't see why this is so great, but I don't understand the syntax used to declare them or attach them to other classes so the delegates' methods get called when any of those methods are called on the object to which the delegate is attached.
Honestly, there isn’t any particular syntax for delegates. Delegates are not part of the language, they’re just a programming convention. (C# is the only language I know of that has special built-in syntax for delegation.)
The delegate pattern basically consists of:
* Define an abstract API of messages the class will send its delegate (in Obj-C this would usually be an @protocol)
* Declare a ‘delegate’ property of the class, whose type is this protocol
* Synthesize the delegate as an instance variable
* Have the class’s methods call the delegate as appropriate when something happens. In some cases they might change the instance’s behavior based on the delegate’s return value.
Again, I can’t recommend Gamma et al's “Design Patterns” book highly enough. The patterns it describes are the basic building blocks of large-scale software design.
> *Every so often I'll see a class between less- and greater-than signs when an example talks about a delegate, but I don't know what this is for. What does it mean to put these symbols around a class (or maybe they are around an object?)?
Those are protocols. The Obj-C language documentation describes them in detail. They’re pretty much equivalent to interfaces in Java.
> -(IBAction) someObject:(id)inSender;
> Huh? Is the (IBAction) casting, or a method call, or what (I understand what IBAction is, but not why it is where it is and in parentheses)? I know why the "id" is there, so this action will work with any UI element, but why the colon? What is inSender doing there, hanging out at the end of the line?
Ummmm … this is just basic Objective-C syntax for declaring a method. If this doesn’t make sense to you, you really need to go re-read the language guide. The only oddity here is that “IBAction” is really just a #define for “void”. It’s a way to flag a method to Interface Builder as being an action method that target actions can be wired up to. The compiler just sees it as a regular method returning void.
As for where the ‘sender’ comes from, the convention is that when a control messages its target, it passes itself as the parameter to the method. That way the object receiving the action can tell what other object invoked the action and can check its properties or whatever. This is passed as a parameter by convention, because there’s no mechanism built into the language to get the object that called a method.
—Jens
_______________________________________________
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