Шаблон Controller

Решение.Делегирование обязанностей по обработке системных сообщений классу, удовлетворяющему одному из следующих условий:

• Класс представляет всю систему в целом, устройство или подсистему (внешний контроллер).

• Класс представляет сценарий некоторого прецедента, в рамках которого выпол­няется обработка всех системных событий, и обычно называется <Прецедент>Handler, <Прецедент>Coordinatorили<Прецедент>Session (контроллер прецедентаиликонтроллер сеанса).

• Для всех системных событий в рамках одного сценария прецедента ис­пользуется один и тот же класс-контроллер.

• Неформально, сеанс – это экземпляр взаимодействия с исполнителем. Сеансы могут иметь произвольную длину, но зачастую организованы в рамках прецедента (сеансы прецедента).

Следствие.Заметим, что в этот перечень не включаются классы, реали­зующие окно, приложение, вид и документ. Такие классы не выполняют задачи, связанные с системными событиями. Они обычно получают сообщения и делегируют их контроллерам.

Проблема.Кто должен отвечать за обработку входных системных событий?

Системное событие(systemevent) – это событие высокого уровня, генери­руемое внешним исполнителем (событие с внешним входом). Системные события связаны ссистемными операциями(systemoperation), т.е. операциями, выпол­няемыми системой в ответ на события.

Например, когда кассир в POS-системе щелкните на кнопке Оплатить, он гене­рирует системное событие, свидетельствующее о завершении торговой операции. Аналогично, когда пользователь текстового процессора выбирает команду Орфогра­фия, он генерирует системное событие "выполнить проверку орфографии".

Контроллер(controller) – это объект, не относящийся к интерфейсу поль­зователя и отвечающий за обработку системных событий. Контроллер определя­ет методы для выполнения системных операций.

Пример.В приложении ТТ существует несколько системных операций (рис. 2.12).

Рисунок 2.12 – Системные опе­рации связаны с систем­ными событиями

В процессе анализа поведения системы системные операции относятся к классу System. Однако это не означает, что их выполняет программный классSystem. Более того, обязанности по выполнению системных операций обычно возлагаются на классController(рис. 2.13).

Какой класс должен выступать в роли контроллера для системных событии типа enteIltem или endSale?

Согласно шаблону Controller, возможны следующие варианты:

Класс, представляющий всю систему в целом, уст­ройство или подсистему.	Register,POSSystem
Класс, представляющий получателя или искусствен­ный обработчик всех системных событий некоторого сценария прецедента.	ProcessSaleHandler,ProcessSaleSession

Рисунок 2.13 – Кто является контроллером для события enterltem?

В терминах диаграммы взаимодействий должен использоваться один из ва­риантов, представленных на рис. 2.14:

Рисунок 2.14 – Варианты контроллеров

Выбор наиболее подходящего контроллера определяется другими факторами, в частности зацеплением и связыванием.

Системные операции, идентифицированные в процессе анализа поведения системы, на этапе проектирования присваиваются одному или нескольким клас­сам контроллеров, например Register(рис. 2.15):

Обсуждение.Большинство систем получает внешние события. Обычно они связаны с графическим интерфейсом пользователя. Кроме того, системе могут передаваться внешние сообщения, например, при обработке телекоммуникаци­онных сигналов или сигналов от датчиков в системах управления.

Во всех случаях при использовании объектно-ориентированного подхода для обработки внешних событий применяются контроллеры. Шаблон Controllerобеспечивает наиболее типичные проектные решения для этого случая. Как вид­но из рис. 2.13, контроллер – это своеобразный вид интерфейса между уров­нями предметной области и графического представления.

Чтобы обеспечить возможность поддержки информации о состоянии прецедента, для обработки всех системных событий в рамках одного прецедента дол­жен использоваться один и тот же класс контроллера. Такая информация может понадобиться, например, для идентификации момента нарушения последова­тельности системных событий (например, выполнение операции makePaymentперед выполнением операцииendSale). Для различных прецедентов можно ис­пользовать разные контроллеры.

Рисунок 2.15 – Распределение системных операций

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

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

Важным следствием применения шаблона Controllerявляется вынесение обя­занностей по выполнению системных событий за пределы уровня представления и внешнего интерфейса объектов (например, объектов окон). Другими словами, системные операции, отражающие процессы в предметной области, долж­ны обрабатываться на уровне логики приложения или реализации объектов, а не на уровне интерфейса.

Объект-контроллер, как правило, относится к клиентской части приложения и функционирует в рамках того же процесса, что и интерфейс пользователя (например, приложение с графическим интерфейсом JavaSwing). Поэтому шаблонControllerнапрямую неприменим, если в качестве клиента выступает Web-броузер. Для такой архитектуры существуют различные шаблоны обработки системных со­бытий, основанные на использовании серверных технических каркасов, в частности на базе сервлетовJava. Чаще всего основная идея сводится к использованию кон­троллеров прецедентов в серверной части приложения, когда обработку каждого прецедента осуществляет либо отдельный сервлет, либо компонент-обработчик сеансаEJB(EnterpriseJavaBeans). Серверный объект-обработчик сеанса обслуживает один сеанс взаимодействия с внешним исполнителем.

Похожие шаблоны:

• Command(Команда) – в системах обработки сообщений каждое сообщение может представлять и обрабатывать отдельный объектCommand.

• Facade(Фасад) – выбор объекта, представляющего всю систему или орга­низацию в качестве внешнего контроллера.

• Layers(Слои) – логи­ка реализации размещается в слое реализации, а не в слое представления.

• PureFabrication(Чистая синтетика) – подразумевает создание искусственного класса, не имеющего аналога в предметной области. Элементом шаблонаPureFabricationявляется кон­троллер прецедента.

Проектирование объектов и карты CRC

Для распределения обязанностей и выявления взаимодействия между объектами иногда используется еще одно средство, формально не являющееся частью языка UML–карты CRC(CRCcards–Class-Responsibility-Collaboratorcards). Они были введены Кентом Беком (KentBeck) и Уордом Каннингхемом (WardCunningham), которые внесли значительный вклад в повышение абстрактности мышления разработчиков объектно-ориентированных систем и уделили большое внимание распределению обязанностей и взаимодействию объектов.

Карты CRC– это индексные карты (по одной на каждый класс), на кото­рых кратко описаны обязанности классов и перечислены объекты, взаимодейст­вующие с данным классом при выполнении этих обязанностей.

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