Относительные преимущества создания собственного протокола и делегата в target -c - PullRequest
0 голосов
/ 15 сентября 2011

Мне было интересно, каковы относительные преимущества использования пользовательских протоколов и делегатов по сравнению с другими методами для достижения двунаправленного класса связи?

Другим решением, например, является следующее:

A связан с B B связан с A

Таким образом, и A, и B имеют доступ к информации друг друга ...

Я как бы понимаю, что протоколы позволяют увеличить модульность конструкции системы, но я не совсем уверен, почему и как?

Ответы [ 4 ]

2 голосов
/ 15 сентября 2011

Пользовательский протокол делегата - отличная вещь, он позволяет вашему объекту не зависеть от конкретного класса.Любой объект, который соответствует данному протоколу, может быть делегатом.Например, любой объект может быть делегатом для табличного представления, если он реализует протокол NSTableViewDelegate.

В противном случае, если вы используете прямую связь, вы должны использовать объект определенного класса.

0 голосов
/ 15 сентября 2011

Обычно нет необходимости, чтобы 2 объекта имели полную двунаправленную связь.
Обычно в iPhone вы запускаете B из A (например, детализированный контроллер представления из контроллера представления списка) и устанавливаете A в качестве делегата B, чтобы он получал прямое уведомление о соответствующих событиях.

С точки зрения объектно-ориентированного проектирования / программирования неправильно соединять 2 объекта в полностью двунаправленном соединении.
В этом случае вы теряете инкапсуляцию.

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

Таким образом, объекты также не должны сохранять друг друга ...

0 голосов
/ 15 сентября 2011

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

Вы слишком сильно привязываете свои классы, когда одной из целей ОО-программирования является уменьшение связи между компонентами.

Даже если вы можете это сделать, это не значит, что это хорошая практика.

Хорошей практикой было бы указать 2 протокола: один для сервера / объекта / производителя / ... и один для клиента / делегата / потребителя /...

Тогда А реализовал бы один протокол, поговорил бы с объектом, реализующим второй. В реализовал бы второй протокол.

В конце концов, это означает, что в будущем вы сможете заменить реализацию B на новую API / модель программирования / тестовую заглушку и т. Д.

Уменьшение связи - это средство, помогающее модульности и тестируемости вашего кода.

Вам не нужно, но вы будете рады вернуться к своему коду через 6 месяцев:)

0 голосов
/ 15 сентября 2011

При использовании шаблона делегата (в частности, использования протокола) классы остаются слабо связанными. Это важно при рассмотрении шаблона MVC. Шаблон делегата позволяет отделить представление от контроллера.

Кроме того, «A, связанный с B B, связанный с A», создает цикл сохранения. Шаблон делегата кодифицирует проблемы управления памятью (то есть класс не должен сохранять своего делегата).

...