Шаблоны проектирования для фреймворков Apple Cocoa: MVC, MVP, Passive View Куда движется Apple?

В любом коде любой сложности есть множество мест, где могут применяться различные шаблоны. MVC занимает видное место в документах Cocoa, потому что он объясняет отношения между вашим функциональным кодом (моделью), вашим кодом пользовательского интерфейса или дизайном IB (представление) и службами Cocoa, которые связывают их вместе (контроллер). Это стоит подчеркнуть, особенно во вступительной части, потому что вам нужен небольшой «тревожный звонок», чтобы перестать думать, что вы должны написать все это самостоятельно, и начать думать о том, как спроектировать свои уникальные части, и доверить фреймворк сделать свою работу. сантехнические работы.

О вариантах определения MVC ходят легенды, и стоит отметить, что MVC не описан в канонической книге «Банды четырех» «Шаблоны проектирования». Также стоит признать, что модель Cocoa «MVC» отличается от модели SmallTalk 80 MVC (отсюда и возникла терминология).

Вероятно, также стоит отметить, что «GoF» на самом деле использует слово «шаблон» для обозначения определенного стиля документации, а не абстрактного способа разработки кода, который описывает шаблон. Жаль, что это использование в значительной степени было утрачено. Если бы мы все понимали это слово таким образом, то я мог бы сказать: «Было бы очень полезно, если бы кто-нибудь на самом деле написал шаблон для Cocoa MVC». Тогда бы мы все не были так растеряны!

Cocoa основан на MVC (как Apple определяет это) и всегда стремится делать больше и многое другое для вас. Вот как обстоит дело в настоящее время.

• Уровень представления: NSView, NSWindow, NSCell, их подклассы и CALayer.
• Уровень контроллера (начиная с 10.3): NSController и подклассы (преимущественно NSArrayController)
• Уровень модели: традиционно вам приходилось делать это полностью самостоятельно, но с версии 10.4 вы можете использовать Core Data.

Крепления питаются от KVO (и KVC) и представляют собой клей, соединяющий три слоя вместе. Вы привязываете представления к контроллерам, а контроллеры к модели.

Я бы не сказал, что Cocoa следует шаблону пассивного просмотра, как он описан здесь. Это говорит о том, что контроллер выполняет всю работу по подготовке представления и отправке уведомлений об изменениях. В Cocoa объект представления обычно отвечает на уведомления KVO (через привязки) от модели, обновляет данные из контроллера, к которому он привязан, подготавливает их с помощью средств форматирования данных или преобразователей значений и, наконец, отображает их на экране.

Cocoa довольно хорошо следует MVC, хотя обычно аспект «контроллера» делится на контроллеры представления и контроллеры модели. Подробнее об этом можно прочитать здесь. Если у вас есть какие-то конкретные примеры того, где вы запутались, возможно, я могу предоставить более подробную информацию о том, как работает Cocoa.

Из того же руководства в этом разделе объясняются некоторые дополнительные шаблоны проектирования, которые могут оказаться полезными. По моему собственному опыту, хотя после работы над несколькими проектами MVC в Cocoa имеет тенденцию происходить довольно естественно, я бы не слишком беспокоился об этом.

Я не думаю, что Cocoa/OpenStep когда-либо действительно следовали MVC, как это описано, например, в SmallTalk 80. Контроллер SmallTalk на самом деле отвечает за интерпретацию взаимодействия пользователя с представлением, которое в случае с Cocoa обрабатывается NSControl и, следовательно, уровнем представления (возможно, это декомпозировано таким образом внутри фреймворка, но мы не должны загляните внутрь; вот что такое абстракция :-). Что касается этих ваших ссылок, уровень контроллера в Cocoa действительно подпадает под баннер Presenter, особенно при рассмотрении различных классов NS*Controller из Cocoa Bindings. Это действительно шаттл между слоем представления и моделью.

В моих собственных приложениях я обычно использую четыре отдельных слоя, даже в тех местах, где они не разделены явным образом; вид, ведущий, сервис и модель. Тогда «контроллеры презентаторов» и «контроллеры служб» имеют совершенно разные цели; логика и процессы находятся в сервисах, а рабочий процесс и варианты использования — в контроллерах представлений. С точки зрения упаковки, если вы занимаетесь такими вещами, сервисы и модель вместе представляют собой абстрактное «что делать с материалом», которое может быть независимым от контекста. Презентаторы и представления представляют «и вот как пользователь приложения Mac OS X хотел бы его использовать», который зависит от нижнего пакета и инкапсулирует классы и поведение, специфичные для AppKit (и специфичные для AHIG).

Apple docs на самом деле объясняет MVC лучше, чем что-либо еще, что я читал. В основном путаница, связанная с MVC, связана с тем, что это составной шаблон. Он состоит из множества основных шаблонов. Хотя MVC не обсуждался в Шаблоне проектирования Бандой четырех, основные шаблоны обсуждались.

Основное отличие, я думаю, заключается в том, что в мире Apple контроллер является шаблоном посредника в дополнение к тому, чем он обычно является.

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

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

При таком подходе в основном приходится переписывать объекты контроллера. Конечно, Apple изменила это с помощью привязок. Но если вы не используете привязки, контроллеры зависят от приложения.

Использование Apple MVC в C++

На самом деле я следовал дизайну Apple, когда программировал приложения на C++ с использованием Qt. Представления принадлежат QWidget. Я поместил весь код, связанный с внешним видом, в подкласс QWidget. Затем я делаю свой контроллер подклассом QObject и заставляю его создавать объекты представления и подключать сигналы от QWidgets к слотам в моем контроллере QObject. Мой модельный класс — это обычный класс, который ничего не наследует от Qt и реализует бизнес-логику. Он модифицируется слотами контроллеров.

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

Не уверен, что это кому-то поможет, но я думаю, что иногда проще думать о шаблонах Cocoa в терминах C++, потому что мы привыкли получать объяснение шаблонов в терминах статически типизированного языка, такого как C++ и Java.

О-о. MVC = самый неправильно цитируемый шаблон. Я прочитал по крайней мере 5 различных определений этого.

Вы можете прочитать эту статью Мартина Фаулера