Делегаты в Objective-c

Question

Является ли обычной практикой в ​​цели c использование контроллера в качестве делегата для различных реализаций протокола. Я говорю об использовании iOS SDK, или это хорошая идея, чтобы иметь отдельные классы, которые принимают роль делегата? Или это просто случай того, что лучше всего подходит к сценарию? Мне в значительной степени любопытно узнать о передовых практиках в Objective c, так как я учусь кодировать их изолированно, и у меня нет эксперта в «реальном мире», к которому можно обратиться.

Answer 1

«Контроллер» ориентирован на владение и фасад. Внешние объекты будут общаться с контроллером, а не с контролируемым. Единственный объект, который обычно должен напрямую общаться с UITableView, это UITableViewController. Контроллер, как правило, владеет контролируемым объектом, и срок службы контроллера должен быть, по крайней мере, таким же, как и у контролируемого объекта.

«Делегат» фокусируется на поведении, стратегии и наблюдателе. Объект запрашивает у своего представителя указания о поведении (я должен показать эти данные? Какого цвета это должно быть? Могу ли я выполнить это действие?). Объект сообщает своему делегату, когда происходят интересные вещи (я был тронут. Я собираюсь что-то закончить. У меня была проблема.) Специальный вид делегата отвечает на вопросы данных (какие данные поступают в строке 3?). Это так называемые источники данных.

В тех случаях, когда для остальной системы характерно общение с «контроллером», обычно нецелесообразно разговаривать с «делегатом». Так, например, обычно уместно иметь указатель на UITableViewController и отправлять ему сообщения из других мест в системе. Неправильно иметь указатель на контроллер tableView; Вы должны работать через контроллер. С другой стороны, если у вас есть указатель на объект, обычно нецелесообразно запрашивать его delegate. Если вам нужно, вы, вероятно, разработали что-то неправильно. (Самым примечательным примером является [[NSApplication sharedApplication] delegate], с которым почти всегда нельзя говорить. AppDelegate - это делегат приложения, а не дамп для глобалов.)

Если объект имеет контроллер, контроллер почти всегда является делегатом. В соответствии с моими правилами, с которыми вы общаетесь, когда объект является и контроллером, и делегатом, тогда это контроллер.

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

Answer 2

1. Хранение делегатов в качестве отдельных классов делает код чистым и переносимым.Вы можете повторно использовать эти классы делегатов для других целей, просто копируя и вставляя их и внося незначительные изменения.

2. Преимущество состоит в том, чтобы хранить делегатов в одном классе, а не в разных классах.Вы можете легко получить доступ к закрытым переменным / объектам в классе, что невозможно в первом случае.

3. Если вы разделяете делегатов и хотите передать какое-то значение главному классу, вам, возможно, придется создать другого делегата :-) или добавить наблюдателей, или вы должны передать их, используя некоторыесвойства.

Answer 3

Краткий ответ: Да, очень часто контроллер представления является делегатом представления (или нескольких представлений), которым он управляет.

Примеры: UITableViewController - это класс, предназначенный для управления экземпляром UITableView, и он реализует протоколы как делегата табличного представления, так и источника данных табличного представления (источник данных - просто еще один вид делегата),Аналогично, было бы естественно, чтобы контроллер представления был делегатом для представления выбора, панели поиска, текстового поля и т. Д.

Обоснование: Представления действительно не должны знатьо том, откуда берутся данные, которые они отображают, но контроллеры представления делают, поэтому для них естественно предоставлять данные и принимать решения о том, как должно вести себя данное представление.То же самое можно сказать и о других типах объектов, но вы должны использовать здравый смысл.Приложение имеет свой собственный объект делегата, который обычно отвечает за создание по крайней мере некоторых контроллеров представления и часто модели данных, поэтому, очевидно, не имеет смысла играть эту роль контроллером представления.

Answer 4

Вот и я:

Предположим, у вас есть класс A и еще один B.

«а» - это объект класса А

В «a», если вы создаете экземпляр B, как «b» и передаете ему self, то есть «a»

Теперь вы можете легко вызвать метод этой переменной "a", которую вы только что передали "b", потому что у вас есть доступ к этому объекту. Но хаос начинается, когда вы закончите с классом B и начнете выпускать «b». Теперь, благодаря использованию «a», вся память, выделенная для «b», будет освобождена, но не освобождена и будет запутана, пока «a» не будет освобождена. Боже, храни вас, если вы используете рекурсивную реализацию класса B.

Следовательно, используя делегат, вы можете использовать все требуемые методы класса А, а также держаться подальше от этой проблемы.

Answer 5

Если вы планируете передавать информацию нескольким частям вашего приложения, NSNotification - это хороший выбор (даже если это может усложнить понимание для других).

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

KVC также является другим способом реализации взаимодействий в вашем коде: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/KeyValueCoding/Articles/KeyValueCoding.html

В зависимости отвы планируете сделать, одно решение может быть лучше, чем другое, лучше всего поиграть с каждым решением, чтобы узнать о них больше ... Это поможет вам принять правильное решение при разработке вашего следующего приложения для iOS!

Answer 6

Лучшая практика зависит от требований, а также с точки зрения кода. Наиболее используемой лучшей практикой является MVC Pattern. Вы получите идею, как только осуществите ее. Есть также некоторые шаблоны проектирования, которые вы можете прочитать. Но для iPhone я предпочитаю MVC. А для делегатов да, это обычная практика в target-c - использовать контроллер в качестве делегата. Объектив-с разработан таким образом.