[DaGuy]

I believe I understand the motivation as well as the usefulness of the delegate pattern throughtout Cocoa. That is step one, in my set of values. Now comes the real fun part.

How do I implement this pattern? Where can I read on simple explicit examples? So far I found lots of literature but zero code examples. It would be great to have two examples: one without IB (an Objective-C tool) and one with IB.

Thanks!

[Chuckit]

I'm not sure exactly what you mean by "implement this pattern." Do you want to implement delegation in your own custom classes, or make use of the delegate methods provided by the Cocoa frameworks?

If it's the latter, then Apple's TextViewDelegate sample code should be useful to you.

Delegation isn't really that complex. It's basically just allowing one object to implement some methods for another, so you don't have to subclass the latter object in order to customize its behavior for your program.

[DaGuy]

Thanks for the link. By "implement this pattern." I just meant the associated code. I'm just looking for some affirmation that I'm thinking about matters correctly. I figured there would be some good Objective C Therapist in this forum who would help me with my Objective-C fears. Below are my thoughts so far.

A delegate is just a logical role that an object plays in a given design and hence any object can be a be a delegate. There is nothing in the Objective-C language that says "this object can be a delegate and this object cannot".

Here's an example of how I would implement a delegate pattern. Say the caller (some control) needs a delegate that implements seven methods and say that three of these methods are required. I would just make the delegate implement a protocol for the three required methods and then have the calling class check to see if the delegate responds to the remaining four optional methods.

Is this the correct way to code it? Any best practices, standard conventions etc.?

Thanks,

[smeger]

Whenever I use a delegate, I give the delegator object a setter & getter - setDelegate: and delegate. setDelegate may or may not retain the delegate depending on the circumstances.

I don't actually implement a formal protocol - I just check to see whether [delegate respondsToSelector: ] and if it's a required method, I throw an exception.

I usually cache the results of [delegate respondsToSelector:] if it's something that'll be called a few times.

[calumr]

Originally posted by DaGuy:
A delegate is just a logical role that an object plays in a given design and hence any object can be a be a delegate. There is nothing in the Objective-C language that says "this object can be a delegate and this object cannot".

What you have described is what I understand to be the role of delegates, so yes, I think you are on the right track . The great thing about delegate/dataSource objects is that you only have to implement some of the methods i.e. if the NSTableView dataSource methods were a formal protocol then you would have to implement the setValueXXX methods even when you only want a read-only table.

[DaGuy]

Thanks a bunch, I feel much better now.

In regards to coding conventions for delegates, I see a couple of things:

1. Methods that support attaching and detaching delegates within the calling class; along with a naming standard.

2. A preference for using exceptions rather than implementing protocols for the handling of the delegate's required methods.

The only reason that I thought about using protocols was to enforce some compile time checks on the delegate. I guess, this is not common practice. Is the use of protocols a waste of energy in the delegate pattern? Any thoughts on the matter?

Thanks!