Protocols and Delegates for Dummies

Question

I've tried to figure this out I promise! There is a wealth of info out there on this and I'm still awash in a sea of abstract concepts! It's like when I was a kid and nobody could explain to me why a country couldn't just print more money and be really rich. I'm not this retarded with most of this stuff, but for some reason I can't wrap my head around this concept, so would really appreciate if someone could spell it out as patronizingly "talking to a 4 year old" slowly as possible!

I think target-action makes complete sense to me. It is a useful way of allowing a view to talk to a controller, without having to do a whole lot. As far as I can make out, a controller object effectively attaches a listener to the view object so that if a particular event occurs on that view (ie button pushed) it fires the controller method. This may not be not technically accurate, but as an abstract explanation it makes sense to me.

So the sequence is:

1. A target method is created in the controller object.
2. A view is selected and graphically connected to that method.
3. An event happens on that view which fires the method from the controller.

Protocols and delegates have me flummoxed. I know it's something to do with allowing objects to talk to each other, but I tried writing out my (lack of) understanding so far below and just deleted it as I think it's best not to unpick the knots in my current thinking but to just wipe the slate and start afresh. If anybody could kindly spend a little time explaining the purpose of

1. Using delegates/protocols as opposed to target/action
2. The constituents of the code, and where it lives
3. The sequence of events which occur when the process is being used

I would be eternally grateful.

Judging by some of the comments on other explanations, I feel I'm not the only one a little bit lost so hopefully this will be of general use. Thanks so much!

Edit:

Okay as I thought maybe if I just lay out my understanding people can correct me, and it might make this easier.

My sample is taken from the Apple Docs, with a Window as the view object and WindowDelegate as the delegate, where a click on the close window button triggers a "should I close?" message to the delegate.

Constituents of the Code: Window (View) WindowDelegate (View Controller?)

1. Declare the protocol which a delegate can use in the interface section of the Window (View).
2. Make an instance of the delegate in the Window.
3. State that the WindowDelegate implements the Window Protocol, by including : in it's interface. (bit wobbly here?)
4. Write the necessary implementation of the methods in the WindowDelegate (View Controller) implementation section.
5. On a certain event the Window will send a message to the WindowDelegate with certain information.
6. The WindowDelegate will process this and return an answer.

Anywhere along right lines?

Answer 1

There is a whole bunch of stuff here and it sounds like you have got a few things confused.

Firstly I'd suggest you go the Apple developer site and download the Learning Objective-C: A Primer and Objective-C Programming Language books. Ignore the target/action interface wiring stuff for the moment because it sounds like you need to understand some basics of Objective C. This is where you will find out all about Protocols, etc and other object orientated stuff.

Secondly there are a number of very good books out there which will take you step by step through developing an application. Beginning iPhone 4 Development: Exploring the iOS SDK is one that is well regarded. THis is also where you will find out about delegates.

Thirdly spend some more time back in the documentation. the SDK documentation has lots of articles outlining how things work from a very basic level and the Apple Developer site has lots as well.

Answer 2

Delegates exist to help you avoid subclassing.

Subclassing is something that you should always try to avoid, since it is a very tight form of coupling. Coupling is when two objects depend on each other to work properly, and the more coupling you have, the more difficult it is to make changes to your program (because whenever you have to change one object, you will be forced to make changes to other objects which depend on it).

The reason subclassing is a form of coupling is because when you subclass from a superclass, your subclass will depend on the superclass's methods (which the subclass inherited). So if you have to change the superclass, then you could possibly have to change all the subclasses with it.

Say you want to have a bunch of objects that are exactly the same, except for what they do with one method. By subclassing, you would have to create a bunch of different subclasses and overwrite that one method on all of them, which would be a lot of subclassing (and unwanted coupling). This is where delegates come in. Rather than subclass a bunch of times, you can simply create the one class, and design it to own an object of the anonymous type id, which will be the delegate object (we'll call it the child). This child object will have the single unique method which was previously in the parent, but now the parent will trigger the method on the child object.

So rather than subclass a bunch of times, we create a bunch of instances of the same class, and give each a different delegate object, which we can do since the type id doesn't specify which type of object we have to use. Each different delegate object implements that method differently, and we avoid subclassing.