Основная идея класса Application Delegate

Question

Какой главный смысл в размещении переменных и сигнатур методов внутри ApplicationDelegate.h в Objective-C? Делая это, все эти методы и переменные видны другим классам контроллера представления? В этом ли смысл?

А также: есть ли только один класс делегата приложения внутри каждого проекта?

Answer 1

Делегат приложения (и да, есть только один на приложение) является основой уровня контроллера в приложениях Cocoa и Cocoa Touch. Его основная функция заключается в настройке поведения NS / UIApplication при определенных обстоятельствах (таких как завершение приложения, открытие приложения и т. Д.). Он также обычно используется для назначения делегатов другим респондентам (таким как табличные представления, схематические представления и т. Д.).

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

Answer 2

"При этом все эти методы и переменные видны другим классам контроллера представления? В этом смысл?"

Конечно, любой класс, который импортирует заголовок контроллера приложения, может получить доступ к общим свойствам и методам (и ivars), но это относится к любому классу, а не только к делегату приложения.

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

Иногда это имеет смысл, но может очень быстро превратиться в очень плохой дизайн . Вы должны убедиться, что делегат приложения не используется как корзина, в которую вы можете просто добавить все общее состояние и функциональность приложения. Я работаю с некоторым кодом, где кто-то сделал это прямо сейчас, и это крайне трудно изменить и изменить функциональность.

Это всего лишь версия известных проблем использования глобального состояния для всего. Короче говоря, вы должны проанализировать функциональность и разделить ее на отдельные классы или группы классов. Постарайтесь, чтобы делегат вашего приложения был максимально тонким!

РЕДАКТИРОВАТЬ: ... и прочитать пост Мэтта Галлахера по этому вопросу.