Нужен ли класс делегата приложения? (дизайнерское предложение)

Question

Мне не ясно, нужно ли создавать класс делегата приложения вместо непосредственного добавления методов делегата в viewcontroller.

Есть ли причина, по которой кто-то хочет иметь отдельный класс делегатов? Стиль предпочтения? Дизайн ограничивает? (Я следую модели MVC, как это делают пользователи и производители приложений Xcode).

Я спрашиваю, поскольку у меня есть 3 книги, которые по-разному объясняют процесс написания приложений; поэтому я хотел бы знать, является ли это просто личным предпочтением авторов, или есть ли что-то другое под капотом (все мои книги по C ++ объясняли концепции одинаково; и теперь, когда я использую OBJ-C и Touch Cocoa , я чувствую себя полностью дезориентированным, когда вижу разные реализации одного и того же приложения).

Еще одна вещь, которая заставляет меня задуматься, это необходимость создания отдельного класса в качестве viewcontroller вместо использования шаблона, который есть в Xcode напрямую (он автоматически создает контроллер представления); поскольку другая книга показывает, как они загружают шаблон, но затем они создают класс viewcontroller с нуля ... опять же, личные предпочтения автора или что-то еще происходит?

Извините, если это звучит просто; но я новичок в OBJ-C :)

Спасибо!

Answer 1

Делегат приложения предоставляет централизованный класс для всего приложения, который можно использовать для координации поведения во всем приложении.Вы можете постоянно получать доступ к своему делегату приложения, используя метод [[UIApplication sharedApplication] делегат] - это невероятно мощный инструмент.

Он также отвечает за обработку поведения, вызванного iOS (applicationDidBecomeActive, applicationWillTerminate и т. Д.), Поэтому имейте в виду, чтохорошее место для соединения некоторых приложений (возможно, вы загружаете их из xib и, например, вам нужно добавить представления) или для обработки логики жизненного цикла приложения.

Внимание!слишком легко злоупотреблять делегатом приложения.Без продуманного дизайна и разработки он может быстро превратиться в неразбериху.Лично у меня есть правило;Я использую его только для работы жизненного цикла приложения и для координации между компонентами моего приложения, и он редко вызывается непосредственно из уровня пользовательского интерфейса.

Answer 2

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

Только постарайтесь не бросать слишком много вещей в этот один объект. Из того, что я прочитал, слишком часто можно сделать из него класс Big Ball of Mud, а не что-то строго определенное. Все, что напрямую не связано с ответственностью делегата приложения, должно идти в какой-то другой контроллер. Делегат приложения является хорошим местом для создания и владения этими контроллерами, поэтому делегату должно быть легко отправлять им любые необходимые сообщения (например, «эй, мы только что получили предупреждение о памяти; очистите некоторые вещи»). 1005 *