Objective-C/Cocoa: Правильный дизайн для делегатов и контроллеров

Question

Рассмотрят следующую общую ситуацию:

У вас есть некоторые MainView в приложении какао, загруженные с СИБ, который управляется с помощью MainViewController. Ваш MainView содержит некоторые элементы управления, такие как UILabel infoLabel. У вас также есть делегат MyDelegate класс, который получает какое-то событие.

Вы хотите удостовериться, что когда MyDelegate принимает свое событие, infoLabel обновляется соответствующим образом. Однако проблема заключается в том, что MyDelegate не имеет ссылки на MainView или MainViewController и не знает о этикетке.

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

Какова надлежащая конструкция для решения этой проблемы?

Answer 1

В безымянном форуме разработчиков, кто-то пишет:

Таким образом, чтобы сделать длинную историю короткой, я решил, что я буду начать использовать NSNotifications. Курс Стэнфорда онлайн, за которым следовали люди, преподается двумя инженерами Apple. Они просто сейчас недвусмысленно сказали НЕ использовать делегат приложения или глобальные переменные и сказали использовать NSNotifications, делегаты и наблюдение K-V.

Если это то, что говорят инженеры Apple, я собираюсь двигаться в этом направлении.

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

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

Answer 2

Обычный шаблон, как вы сказали, передает указатель на MainView через его методы делегирования. Таким образом, если MainView звонит doSomethingWithFoo: метод своего делегата, вы хотите изменить этот метод:

- (void)mainView:(MainView *)view doSomethingWithFoo:(id)foo 

и вызвать новый метод соответственно. Если вы работаете непосредственно с указателем MainView, у вас не должно возникнуть проблем с циклическими ссылками.

Answer 3

Мы реализовали сложный «Data» -объект, который контролирует почти все. Он проверяет наличие изменений и сохраняет все глобальные изменения.

При создании новых экземпляров я отношу к классу данных, как это:

[[Button alloc] initWithData:data]]; 

Где data находится в singelton данных класса. Теперь мы можем проверить, есть ли изменения, необходимые для реагирования.

Я признаю, что он по-прежнему требует ссылок, как вы описали. Кажется, что нет простой ссылки parent.

Answer 4

Вот 2 варианта, которые приходят на ум:

• Если событие собирается делегировать это отправить ваш контроллер, вы можете иметь этот метод возвращает значение к контроллеру, чтобы подтолкнуть к просмотру.

• Вы также можете привязать значение infoLabel к некоторому ключу (используя, скажем, привязки Cocoa или просто необработанное наблюдение за ключевыми значениями). Связанный объект (который может быть делегатом или каким-либо другим объектом модели) может просто обновить связанный ключ, который будет вызывать значение для infoLabel. Например, вы можете связать член «info» делегата с значением infoLabel. Когда делегат получает событие, он может обновить член информации, и представление изменится. Действительное связывание сама может произойти в IB (если ваш делегат в бобах) или в контроллере (который имеет ссылку на вид и делегата.)

Последнее решение в основном циклическая ссылка, но тот, который кажется мне как-то более чистым.