As I build upon my understanding of Objective-C, I’ve been working to better understand the concept of a delegate and when they should be used. In searching for clarity, I came upon an explanation by Mark Hernandez the administrator of iPhoneDevForums.com.
For posterity, I’ve copied Mark’s explanation here. For his full explanation and his code example, follow the link above.
My favorite way to explain how delegates work involves animals.
Let’s say you are going to create a particular bird. You start with a predefined class definition of a bird (provided in the existing framework as, say, CFBird). The existing framework class assumes all birds have certain things in common — they hatch and grow the same, poop the same, fly the same, and lay eggs the same way, etc. (tee hee, I said poop. ) But different birds look different, are different sizes, chirp differently, eat different things, and may mate differently.
So let’s say Apple provided you with the basic bird class (with hatching, growing, pooping, flying and egg-laying behavior already built in).
Here now in this more advanced age of object-oriented design, there’s a concept (design pattern) called “delegation” and it’s a cool way to easily implement custom classes, assuming ahead of time that you’ll likely never need to worry about anything else about creating birds other than specifying how they differ from each other — how they look (size and color) and how they chirp, eat and mate.
So, the people who designed the CFBird class have set up a “protocol” which specifies the “delegate methods” (kinda like “callbacks” in C) which is all your new class will need to implement to create your custom bird, and you’re done! Basically the class is going to call into your code when your particular bird is drawn, when it chirps, eats and mates. These tasks are “delegated” to you in your subclass of CFBird.
Everything else is handled for you, and you only need to concern yourself with what is different about your bird, and forget about what is the same amongst all birds, simplifying your life and making things more consistent.
In your code, when you specify your new class of bird, in the @implementation you’ll make reference to a <protocol>, and by doing so you are telling the system that you agree to implement the methods specified in that protocol which will detail exactly how your particular bird is going to look, chirp, eat, and mate. Done and done.
The subclassing comes first, and the possible delegate methods follow if you specify a protocol to follow.
In this specific case, why would you prefer using a protocol rather than direct inheritance?
Is delegate and inheritance are the same ?
Indeed, good explanation. I don’t know why but this concept is fragile in my mind, even thou I can understand it, I cant recognize it or latter to see its application without thinking of subclassing. But it helped a lot!
Two phish kids were talking about a show that they recently attended. The first said, “That was one of the worst shows I’ve ever been to. Trey sang off key, Mike came in too late, and Page forgot all the words. It was terrible!” The second phish kid replied, “I completely agree with you, dude. And it was way too short, too!”
thank you, very well explained 🙂