On Jun 4, 2013, at 3:27 PM, Alex Zavatone < email@hidden> wrote: If I'm to read in to this, you're saying that there is a promise that these will be implemented - and you're implying that it doesn't matter what implements it, whatever implements it is decoupled from the protocol, but all those protocol methods must be implemented and at runtime, Cocoa can move in (lame term, I know), connect or hook up which ever object it determines needs to be there.
Kind of, but you’re making it seem like a different thing from the way classes normally work, when it isn’t really.
A protocol is like a class, except that - It can’t implement any methods, only define messages in its API. In other words, it’s purely abstract. - Classes can inherit from (implement) one or more protocols in addition to a single base class. - A class that implements a protocol has to implement all the methods of that protocol (except those declared as @optional.)
That’s about it for the differences. Except for little nits like you refer to a protocol as @protocol(Foo) instead of [Foo class] for some reason, and you test for inheritance with -conformsToProtocol: instead of -isKindOfClass:.
(In languages with multiple inheritance like C++ or Common LISP there isn’t any difference between these entities, they’re just different types of classes with or without abstract methods. But in practice multiple inheritance gets really messy to use, so the protocol/interface mechanism was invented as a way to get many of the benefits without all the complexity.)
So mostly you can think of a protocol as a special kind of class. UIApplicationDelegate is an abstract base class that app delegates have to inherit from. It just has the convenience that, since it’s a protocol, your class can inherit from a real base class (like UIResponder) as well, and inherit implementation from it.
—Jens |