iOS / Objective-C App Delegates Explained Using Birds

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.