One of the first patterns you encounter when you’re learning Cocoa is the way Apple’s view classes extend their functionality with delegates.
If Apple does it with their view classes, it must be a great idea for your view classes too, right?
The answer you’re looking for here is “no”.
Let’s play a game of
20 2 questions, shall we?
1. Is your view class (a) a general-purpose class, intended to be used by future clients in ways you can’t anticipate? Or is it (b) a very specific class used in a very specific, single way?
2. Do you have (a) two or more classes serving as delegates for your view? Or is the delegate (b) always the same class, used in exactly the same way, to the point where you’re not even bothering with
If the answers to both questions are (b), then you know what using the delegate pattern buys you for connecting your view class to its “delegate”? That’s right, nothing. And you know what it causes for the people who come in later to maintain your class? A big headache, right again!
For one, they have to spend the time investigating what classes actually serve as the delegate of your view class. They may need to run the app, get it into a variety of hard-to-reproduce states, just to be sure. Certainly, this might not be that big of a deal for one class. But in a large codebase where this “pattern” has been used repeatedly, it can bog things down.
For two, it means they can’t entirely rely on the automated refactoring tools when they want to make changes to the delegate classes. Because delegates are of type
id, right? That’s the pattern. So that bogs things down, too.
Let me spell it out: if you have a view subclass (or any class, really) that needs functionality from an associated class, add a typed reference to that associated class. Don’t add an untyped “delegate” reference.
By all that is holy (donuts, CDs, bowling balls, etc.), don’t create your own DeleGate scandal.
And stay tuned for my next post, where I rant for twenty pages about bindings misuse.