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

Question

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

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

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

Answer 1

РЕДАКТИРОВАТЬ: Еще один хороший пост: NSNotificationCenter против делегирования (с использованием протоколов)?

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

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

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

Что именно делает делегат в проекте xcode ios?

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

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

Answer 2

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

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

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

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

Answer 3

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

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