Шаблон Low Coupling (Низкое Связывание)
Дадим определение степени связности (coupling).
Определение. Степень связности – это мера того, насколько жестко один класс связан с другими классами; иными словами, каким количеством информации о них он обладает.
Проблема. Наличие классов с высокой степенью связности нежелательно, т.к. приводит к следующим проблемам:
изменения в связанных классах обусловливают изменениям в данном классе;
затрудняется понимание каждого класса в отдельности;
усложняется повторное использование.
Решение. Распределять обязанности таким образом, чтобы степень связности оставалась низкой.
Например, в системе розничной торговли необходимо создать платеж и связать его с продажей. Кто этим должен заниматься? На рис. 99 представлены два варианта распределения обязанностей для этой задачи. Второй вариант является более предпочтительным, т.к. в нем на одну связь меньше. Кроме того, второй вариант согласуется с шаблоном Creator, т.к. продажа обладает данными инициализации платежа.
Крайним случаем применения данного шаблона является полное отсутствие связывания. Это тоже плохо, т.к. базовой идеей объектно-ориентированного подхода является система связанных объектов, взаимодействующих при помощи сообщений. Иначе система сводится к нескольким изолированным сложным активным объектам, которые выполняют все действия, и множеству пассивных объектов, основным назначением которых является хранение данных.
Рис. 99. Два варианта распределения обязанностей при создании платежа
Применение данного шаблона приводит к локализации изменений, простоте понимания и легкости повторного использования классов.
Шаблон High Cohesion (Высокое Зацепление)
Дадим определение зацеплению (cohesion).
Определение. Зацепление (а точнее, функциональное зацепление) – это мера связанности и сфокусированности обязанностей класса. Класс обладает высокой степенью зацепления, если его обязанности тесно связаны между собой и он не выполняет работ непомерных размеров.
Проблема. Наличие классов с низкой степенью зацепления, которые выполняют много разнородных обязанностей, приводит к следующим проблемам:
трудность в понимании;
сложности при повторном использовании;
сложности при поддержке;
постоянная подверженность изменениям.
Решение. Распределять обязанности таким образом, чтобы поддерживалась высокая степень зацепления.
Рассмотрим применение данного шаблона на том же примере, что и шаблон Low Coupling. В первом случае на рис. 99 экземпляр системы розничной торговли (:СРТ)частично отвечает за проведение платежа. В данном случае это не очень плохо, но если дальше возлагать на него обязанности, то класс будет перегружен, и будет обладать низкой степенью зацепления. Во втором случае обязанность делегирована продаже, что предпочтительнее.
Использование шаблона Low Coupling приводит к легкости в понимании классов и в их поддержке и повторном использовании.
Шаблон Controller (Контроллер)
Проблема. Кто должен отвечать за обработку системных сообщений?
Решение. Делегировать обязанности по обработке системных сообщений классу, удовлетворяющему одному из следующих условий:
класс представляет всю систему в целом (внешний контроллер), например «СРТ».
класс представляет всю организацию (внешний контроллер), например «Магазин».
класс представляет активный объект из реального мира (котроллер роли), например «Кассир».
класс представляет искусственный обработчик всех системных сообщений в рамках некоторого прецедента (контроллер прецедента), например «ПродажаТовара».
В любом случае для всех системных сообщений в рамках одного прецедента должен использоваться один контроллер.
Заметим, что в указанный выше перечень не включены объекты интерфейса пользователя. Обработка системных сообщений на уровне интерфейса пользователя является довольно распространенной ошибкой проектирования, которая приводит к серьезным проблемам при поддержке и повторном использовании. На рис. 100 представлен пример использования шаблона Controller.
Применение шаблона Controller позволяет контролировать состояние прецедента, т.к. все системные сообщения прецедента обрабатываются в одном месте. Кроме того, система получается независимой от уровня представления, что позволяет легко изменять интерфейс пользователя и поддерживать сразу несколько интерфейсов (например, WinForms, Web-интерфейс, интерфейс для мобильных устройств и т.д.).
Рис. 100. Использование шаблона Controller
На практике рекомендуется использовать контроллеры прецедентов, а если системных сообщений мало, то любой внешний контроллер.
Вопросы для самоконтроля
Опишите каждый из шаблонов.
Какой шаблон является наиболее общим?
Что такое связывание и зацепление?
Какие бывают контроллеры и зачем они нужны?
Задания для самостоятельной работы
Переделайте Ваши диаграммы сотрудничества и диаграммы классов с учетом рекомендаций, описанных выше в шаблонах GRASP.