Различия в использовании делегатов и нотификаций. Пример

Делегаты. Основной идея:контроллер определяет протокол (набор определений методов), которые описывают то, что объект делегата должен сделать для того, чтобы иметь возможность реагировать на события А контроллера. Протокол представляет собой договор, где доверитель говорит: «Если вы хотите быть моим делегатом, то вы должны реализовать эти методы». Это позволяет контроллеру вызывать методы на его делегат с осознанием того, что делегат будет реагировать на вызовы методов. Делегат может быть любого типа объекта, так что контроллер не связан с конкретным объектом, но он все еще может быть уверен, что делегат будет реагировать, когда он пытается сказать ему что-то.

+ Очень строгий синтаксис. Все события, чтобы быть услышанными четко определены в протоколе делегата. Время компиляции предупреждений / ошибок, если метод не реализован, как это должно быть делегатом. Протокол определен в пределах только контроллера. Возможность иметь несколько протоколов определяющих один контроллер, каждый с различными делегатами. Ни один объект третьей стороны не требуется для поддержания / мониторинга процесса коммуникации. Возможность получать возвращаемое значение из называемого метода протокола. Это означает, что делегат может помочь предоставить информацию обратно к контроллеру.- Много строк кода, необходимого для определения: 1. определение протокола, 2. свойство делегата в контроллере, и 3. внедрение определений методов делегата внутри самого делегата. Уведомления В приложениях IOS есть понятие «Центр уведомлений». Это единичный объект, который позволяет объектам получать уведомления о происходящих событиях. Это позволяет удовлетворить цели обмена данных между контроллером и произвольным объектом с низким уровнем сцепления. Основная концепция этой модели является то, что контроллер использует ключ (имя уведомления) для того, чтобы позволить другим объектам услышать о специальных событиях, происходящих внутри контроллера. Тогда неведомые контроллеру, другие объекты (наблюдатели) могут реагировать на событие уведомления пути регистрации уведомлений с тем же ключом. + Простота внедрения, немного строк кода. Можно легко иметь несколько объектов, реагирующие то же опубликованное уведомление.-1) Нет компиляции, чтобы убедиться в том, что уведомления правильно обработаны наблюдателями. Требуется отмена регистрации с центром уведомлений, если ваш ранее зарегистрированный объект освобождается. -2)Не очень прослеживается. Попытка отладки проблем, связанных с потоками данных и управления может быть очень трудна. -3)Третий объект, необходимый для управления связью между контроллерами и объектами наблюдателей. 4)Нет возможности у контроллера получить какую-либо информацию обратно от наблюдателя после того, как уведомление опубликовано


Понравилась статья? Добавь ее в закладку (CTRL+D) и не забудь поделиться с друзьями:  



double arrow
Сейчас читают про: