Делегаты против событий в Cocoa Touch

Question

Я пишу свое первое приложение для iPhone, и я изучаю шаблоны дизайна в Cocoa Touch и Objective-C. Я исхожу из среды веб-разработки на клиентской стороне, поэтому я пытаюсь обернуть голову делегатами.

В частности, я не вижу, почему объекты делегата необходимы вместо обработчиков событий. Например, когда пользователь нажимает кнопку, он обрабатывается событием (UITouchUpInside), но когда пользователь заканчивает ввод в текстовое поле и закрывает его кнопкой «Готово», действие обрабатывается вызовом метода на делегат текстового поля (textFieldShouldReturn).

Зачем использовать метод делегата вместо события? Я также замечаю это в контроллере представления с помощью метода viewDidLoad. Почему бы просто не использовать события?

Answer 1

EDIT: Еще один хороший пост: NSNotificationCenter vs delegation(using protocols)?

делегат обратного вызова, так есть 1: 1 отношения. Делегат - это единственный экземпляр объекта, который реализует формальный протокол.

Уведомления (события) в основном транслируются по многим объектам, которые интересуются, когда что-то происходит.

Делегаты хороши для возможности вставлять код в трубопровод некоторых других объектов обработки, такими, как до и после обратных вызовов, обеспечивая источники данных для управления и связи между видами:

What exactly does delegate do in xcode ios project?

Поэтому делегаты имеют гораздо более тесную связь с объектом, поскольку они являются единственным предоставленным объектом для вставки и изменения обработки объекта или предоставления данных. Вы откладываете решения и внешние операции, такие как загрузка данных на какой-то другой объект - вот почему это очень распространенный шаблон для общих классов UIKit. Уведомления для других объектов - это гораздо более свободные отношения - это просто уведомление о том, что что-то произошло.

Это тоже не вопрос «против». Например, у вас может быть приложение, выполняющее фоновую обработку, и оно произвело что-то измененное уведомление, из-за чего представление вызывало его делегата источника данных, чтобы обновить его представление. Это два разных механизма.

Answer 2

Одно четкое различие заключается в том, что методы делегата могут иметь возвращаемые значения, поскольку существует взаимно-однозначное отношение. С другой стороны, события слабо связаны с отправляющим классом, который обычно не волнует, если что-либо ответит или нет.

Другие методы делегатов просто для удобства и могут иметь соответствующие события, которые также запускаются.

Answer 3

События и делегаты имеют две разные цели, поэтому вы увидите, что оба используются.

Если вы хотите, чтобы ваша кнопка нажала кнопку, чтобы отключить сообщение, событие прекрасное. Если вы хотите, чтобы ваша кнопка Done нажала для подтверждения контекста текстового поля, прежде чем ему удастся потерять фокус, вы можете использовать метод делегата textFieldShouldReturn для обработки любой проверки и возврата НЕТ, если он не подтвержден.

Делегаты действительно позволяют изменять поведение без подкласса. Они заполнены должны и сделали методы для этой цели.Вы применяете эти методы вместо переопределения методов действий, когда вы хотите проверить, уведомить или обработать до и/или после действия.

Если вы считаете, что вам нужно подклассифицировать объект UIKit, сначала проверьте его методы делегирования. Скорее всего, есть место, где можно поместить свое поведение.