Вот способ думать о делегате - в типичном примере ООП у меня есть объект автомобиля. Я не хочу когда-либо снова создавать его подкласс, я просто хочу использовать его как есть, так как мне заставить его действовать как шеви или мустанг? Я даю это делегату.
У моей машины были бы методы, чтобы управлять, методы, чтобы сигналить и т. Д.
У моего делегата были бы такие методы, как «какова моя максимальная скорость» и «как звучит гудок» и «окрашены ли мои окна»
Поэтому, когда я вызываю -drive для моего автомобильного объекта (который не разделен на подклассы), этот метод вызывает метод topSpeed моего делегата, и делегат сообщает ему 120 миль в час, поэтому автомобиль знает, как быстро он должен идти, не будучи мустанг.
в Задаче C обычно есть протокол, который определяет, на что должен ответить делегат, т. Е. Для делегата моего автомобильного объекта был бы протокол, объявленный так:
@protocol carDelegate
-(int)carTopSpeed;
-(UIColor*)carColor;
-(BodyShape*)carBodyShape;
-(DragCoefficient*)carDragCoefficient;
-(HoodOrnament*)carHoodOrnament
@optional
-(BOOL)windowsTinted;
@end
Затем вы можете создать свой собственный объект, который соответствует этому протоколу (реализует все необходимые методы и любые необязательные, которые рассматриваются как необходимые)
И объект car ожидает, что (id) будет передан ему как делегат.
Тогда автомобильному объекту удалось избежать подкласса, и он все еще может вести себя в соответствии с потребностями пользователя.