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

Question

Чтобы заложить основу для этого вопроса, я хочу заявить, что я получаю свои определения для MVC, MVP и Passive View из следующего:

Контроллер модельного представления (MVC)
Ведущий модели (MVP)
Пассивный просмотр (PV)

Apple всегда заявляла, что использует шаблон проектирования MVC, но я заметил, что в OS X 10.5 мы получили NSViewController, KVO, привязки и т. Д. Объекты, которые, похоже, ведут себя больше как шаблон проектирования Passive View. Это то, где Apple хочет, чтобы мы возглавили? Я хочу спланировать свой код так, чтобы он наилучшим образом соответствовал выбранным Apple шаблонам проектирования, поэтому я хочу знать, куда движется Apple. У кого-нибудь есть подсказка?

Answer 1

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

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

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

Answer 2

Какао - это на основе MVC (как Apple определяет его ), и всегда была тенденция делать для вас все больше и больше. Вот как это сейчас.

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

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

Answer 3

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

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

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

Answer 4

Документы Apple на самом деле объясняют MVC лучше, чем что-либо еще, что я читал. В основном путаница, связанная с MVC, заключается в том, что это сложный паттерн. Он состоит из многих основных моделей. Хотя MVC не был обсужден в Design Pattern Gang из четырех , основные шаблоны были.

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

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

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

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

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

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

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

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

Answer 5

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

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

Answer 6

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

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