Why is Class delegation so enigmatic?
This is probably another thick, newbie question that will have everyone smacking their foreheads and going 'Duhhhhh!' BUT, after another long spell of reading and watching countless Brad Larson videos, I'm left perplexed at why delegation in general and CALayer delegation in particular seems to be such an enigmatic theme.
All the books and Dr Larson bang on about 'not sub-classing CALayers' unless you want a high degree of encapsulation but nowhere have I found a succinct and to-the-point example of the benefits that CALayer delegation can offer. Everyone seems to use either, the host view controller object as a, sort开发者_Go百科-of, perfunctory delegate or they shovel everything into the App delegate "as a brief example of what can be achieved".
I'm trying to learn "BEST PRACTICE" up-front - because I'm so new and because I don't want to develop any bad or slovenly programming traits - so I'm keen to examine each new step I take in minute detail. From what I can gather, a CALayer delegate class only has about 3 delegate-specific methods in it. These are 'displayLayer:', 'drawLayer:InContext:' and 'actionForLayer:ForKey:'. In my Opacity-generated Quartz stuff, I have used colour variables which I want to manipulate at runtime and do so without sub-classing CALayer. One of the side-effects of using Key-Value pairs is that there exists a class method called 'defaultValueForKey:' which describes the initial value of my colours according to the key value used to identify them. This is NOT (apparently) a CALayer delegate method. So how can I implement this code (which, after, all only sets a default value) without sub-classing CALayer? It seems that delegation is OK as long as you only need the few delegate-specific methods.
Could anyone explain why, when implementing delegation, the boffins at Apple didn't simply transpose the method-definition compilation unit from the class unit to the assigned delegate unit. e.g. Simply place an initial parameter in front of every method usually available in the class (or sub-class) by the phrase; 'forLayer: (CALayer *) TheRest: OfThe: method'? This way a simple switch or if-then stack could apply the usual method-ry of the class in one centralised object - the delegate.
As I said at the beginning, I'm probably missing something pretty basic but could anyone tell me how I implement all my key-value colour variable inits without sub-classing CALayer?
Thanks in advance, V.V.
You're over thinking it all. As you mentioned, you're new to the platform. There are many idioms in Cocoa, but one of the idioms is a bit like Perl: "there's more than one way to do it".
Cocoa has a history of delegation because much of the time, you just need a method or two, and who wants the complexity of a zillion classes with few methods. Delegates let you work around that in a simple way.
So, basically rather than analyzing everything from the overall engineering point of view, just use the platform. Write some code. Write some code the "wrong way". Write lots of it.
Why? Because if it's the "wrong way", you will feel it yourself. You'll start cursing it in maintenance or whatever, and then you'll figure out the "right way". What is the "right way"? The way that feels better for YOU.
Most of these decisions have minimal impact on performance, etc., so don't worry about it. And because of that, it doesn't really matter which technique you choose.
Write code. Write lots of it. The more you write the more you'll get a feel as to when what technique is right, and which one is wrong. Or when the right way before now becomes the wrong way and should be refactored in to the new right way.
Because what's right or wrong now may not be later.
精彩评论