Ну, это зависит. Вся концепция протоколов делегатов существует, так что вы можете иметь большую гибкость. Иногда вы берете маршрут по умолчанию, но иногда вам нужно иметь возможность использовать множество различных классов делегатов.
(1) Делегат приложения - делегат приложения должен использоваться только для методов UIApplicationDelegateProtocol или делегатов для реальных свойств самого экземпляра делегата. Другими словами, если делегат приложения не имеет непосредственного отношения к экземпляру, например объект приложения, тогда делегат приложения должен служить делегатом экземпляра. Накапливание посторонних методов в делегате приложения приведет к путанице в приложении и затруднит его отладку и обслуживание.
(2) Полностью отдельные классы делегатов обычно используются, когда у вас есть (A) большое количество протоколов делегатов для реализации или (B) у вас один и тот же протокол для реализации для нескольких экземпляров, но требуется другое поведение для делегата каждого объекта , Например. у вас есть несколько UITextFields, каждое из которых ведет себя по-разному. Вы создаете отдельный класс делегата для каждого так, чтобы у каждого текстового поля была своя собственная реализация методов протокола делегата.
(3) Использование контроллера для делегатов - это самый простой, логичный и модульный способ в большинстве случаев. Во многих случаях, таких как элементы пользовательского интерфейса, методы делегата нуждаются в понимании других элементов пользовательского интерфейса, которые может предоставить контроллер.
В итоге, никогда не используйте (1) в качестве общего места для парковки для любых случайных методов делегирования и по умолчанию (3) в большинстве случаев.