Избегать связывания в основанном на документе приложении Какао?

Question

Я новичок в программировании на Mac и работаю над документным приложением.

Мой подкласс NSDocument создает подкласс NSWindowController. Этот оконный контроллер также создает два NSViewController подклассы.

Иногда, при изменении одного из представлений NSViewController необходимо уведомить NSDocument и / или основной класс модели. Кроме того, об изменении модели необходимо уведомлять каждое / несколько представлений.

Мой вопрос: каков наилучший подход, чтобы не было (или минимум) связи? Я знаю, что есть несколько вариантов, но я не уверен, какой из них лучше всего подходит для моего приложения, так как я новичок не в программировании, а в Какао и особенно NSDocument:

• KVO. Выглядит красиво и легко для реализации, но мне не нравится идея не явно уведомлять наблюдателя (ей) об изменении (AFAIK, self.someProperty = newValue автоматически уведомляет наблюдатели), и вам не нравится тот факт, что вы должны зарегистрироваться на имена свойств, которые могут изменяться со временем.

• Уведомления. Я знаю, что это такое, и я использовал их для iOS. Но я где-то читал, что они не гарантированно будут немедленно отправлены наблюдателям. Это правда? Если нет, считаете ли вы их хорошим подходом для приложений на основе документов?

• Делегаты. Да, при нормальных условиях (или что я обычно видел) у класса есть один делегат. Но создание массива делегатов также работает (только что проверил). Проблема, которую я вижу здесь, заключается в том, что каждый раз, когда мне нужно уведомить делегатов, я должен пройти через них, убедиться, что они отвечают на метод, и вызвать этот метод.

Есть ли еще какие-то альтернативы, которые мне не хватает?

Answer 1

Да, в нормальных условиях (или что я обычно видел) у класса есть один делегат.Но создание массива делегатов также работает (только что проверил).

Делегаты часто используются для изменения поведения делегирующего объекта.Хороший пример - делегат приложения: само по себе NSApplication не очень интересно;он полагается на своего делегата для определения интересного поведения приложения.Наличие нескольких делегатов, пытающихся изменить поведение одного объекта, может быть проблемой, если различные делегаты конфликтуют друг с другом.Что вы делаете, если делегаты не согласны?

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

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

Это не трудно решить.Например, вы можете создать NSInvocation для инкапсуляции вызова, а затем отправить вызов каждому «делегату».Однако, если вы сделаете это, вы почти заново изобрели систему уведомлений.Если вам нужно общение «один ко многим», которое вы получите с вашим предложением для нескольких делегатов, вам, вероятно, будет лучше использовать уведомления или KVO.

Answer 2

KVO по классу контроллеров является наиболее распространенным способом связи модели с ее представлениями.Фактически, привязки Какао, которые в основном предназначены для устранения кода на уровне контроллера, основаны на KVO.Это правда, что KVO / KVC опирается на имена свойств, и если они меняются, вам придется изменить привязки или настройки KVO, связывающие ваше представление.Однако, как правило, невозможно сделать ваши представления полностью неосведомленными о специфике лежащей в основе модели, поэтому я не вижу в этом проблемы.

Я бы порекомендовал использовать привязку Какао там, где это возможно, так как они устраняютмного клеевого кода.В местах, где их нельзя использовать, ваши контроллеры (средний уровень в MVC) должны использовать KVO для наблюдения за изменениями модели и обновления соответствующих представлений.Изменения в представлениях могут передаваться обратно в модель через средства доступа к свойствам и / или KVC контроллерами.