Pull to refresh

GRASP паттерны проектирования

Reading time 4 min
Views 231K
Почитать описание других паттернов.

GRASP (General Responsibility Assignment Software Patterns) — шаблоны проектирования, используемые для решения общих задач по назначению обязанностей классам и объектам.

Известно девять GRAPS шаблонов, изначально описанных в книге Крейга Лармана «Применение UML и шаблонов проектирования». В отличие от привычных читателю паттернов из Банды Четырех, GRAPS паттерны не имеют выраженной структуры, четкой области применения и конкретной решаемой проблемы, а лишь представляют собой обобщенные подходы/рекомендации/принципы, используемые при проектировании дизайна системы.

Рассмотрим характеристики основных GRASP шаблонов.

Предметная область


Для более детального понимания читателем GRASP шаблонов, будут описаны примеры их использования из предметной области морских грузоперевозок.

Судоходная компания «Навигатор+» является крупнейшим поставщиком услуг морских грузоперевозок. Головной офис компании состоит из трех отделов: отдел по работе с клиентами, отдел диспетчеризации рейсов, отдел комплектации рейсов. Менеджеры из отдела по работе с клиентами оформляют договора на доставку груза из пункта А в пункт В. Диспетчеры из отдела диспетчеризации рейсов отслеживают положение судов. Администраторы из отдела комплектации рейсов формируют грузовые рейсы на основании договоров с клиентами.

Информационный эксперт (Information Expert)


Шаблон информационный эксперт является базовым и в то же время самым очевидным из девяти. Информационный эксперт описывает основополагающие принципы назначения обязанностей классам и объектам. Согласно описанию, информационным экспертом (объектом наделенным некоторыми обязанностями) является объект, обладающий максимумом информацией, необходимой для выполнения назначенных обязанностей.

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


Применение шаблона информационный эксперт повышает связность модулей и не противоречит свойству инкапсуляции.

Низкая связанность (Low Coupling) и Высокое зацепление (High Cohesion)


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

Рассмотрим понятие меры связности модулей и меры зацепления модуля. Мера связности модулей определяется количеством информации которой располагает один модуль о природе другого. В свою очередь, мера зацепления модуля определяется степенью сфокусированности его обязанностей.

Стоит отметить, что существуют методологии, согласно которым меры связности и зацепления можно оценить по шкале от 1 до 10 для конкретного случая. Однако, в рамках данной статьи они на рассматриваются.

Примером хорошего дизайна системы может служить набор утилит GNU Binutils для Linux. В котором, каждая утилита (если ее рассматривать как модуль) выполняет лишь минимальные обязанности (высокое зацепление) и почти ничего не знает о природе других утилит (низкая связность), в связи с чем может быть легко заменена на аналог в некотором варианте использования.

Устойчивый к изменениям (Protected Variantions)


Проблема модификации системы наиболее актуальна в условиях динамически изменяющихся требований. Зачастую, удается выделить т.н. точки неустойчивости системы, которые наиболее часто будут подвержены изменению/модификации. Тогда, сущность шаблона устойчивый к изменениям заключается в устранении точек неустойчивости, путем определения их в качестве интерфейсов и реализации для них различных вариантов поведения.

Например, рассмотрим ситуацию расширения спректра услуг компании «Навигатор+». Будем считать, что судоходная компания начала заниматься пассажирскими перевозками. Для этого, реализуем точку устойчивости системы — перевозимую сущность (Entity).


Контроллер (Controller)


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

Известно понятие внешнего контроллера (Front Controller), который представляет всю систему в целом (агрегирует весь функционал системы в одном классе).

Примером контроллера является класс Administrator, реализующий вариант использования системы администратором из отдела комплектации рейсов.


Использование контроллеров позволяет отделить логику от представления, тем самым повышая возможность повторного использования кода.

Полиморфизм (Polymorphism)


Шаблон полиморфизм позволяет обрабатывать альтернативные варианты поведения на основе типа. При этом, альтернативные реализации приводятся к обобщенному интерфейсу.

Рассмотрим интеграцию системы с внешними компонентами расчета тарифов на перевозку груза. Классы LocalTarificator и WorldWideTarificator являются адаптерами к соответствующим внешним компонентам.


Применение шаблона полиморфизм позволяет в будущем легко модифицировать систему.

Чистая выдумка (Pure Fabrication)


Существует понятие модели программирования по предметной области, согласно которой, каждой сущности из предметной области соответствует один или более классов программной среды. При этом, обязанности взаимодействия сущностей, как правило накладываются на них самих. Такой подход имеет очевидный недостаток — высокая связность модулей системы. Шаблон чистая выдумка позволяет решить данную проблему, путем введения в программную среду дополнительного класса (не отражающего реальной сущности из предметной области) и наделение его требуемыми обязанностями.

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


Применение шаблона чистая выдумка позволяет дизайну системы соответствовать принципам низкой связности и высокого зацепления.

Перенаправление (Indirection)


Шаблон перенаправление реализует низкую связность между классами, путем назначения обязанностей по их взаимодействию дополнительному объекту — посреднику.

Примером данного шаблона может служить класс ClientsSaver (см. Чистая выдумка), который является промежуточным слоем между сущностями клиентов и хранилищем, в котором они будут сохранены. Кроме того, контроллер из триады MVC является посредником между данными их их представлением.
Tags:
Hubs:
+33
Comments 24
Comments Comments 24

Articles