GRASP

GRASP (англ. general responsibility assignment software patterns — общие шаблоны распределения ответственностей; также существует английское слово "grasp" — «контроль, хватка») — шаблоны, используемые в объектно-ориентированном проектировании для решения общих задач по назначению ответственностей классам и объектам.

В книге Крэга Лармана «Применение UML и шаблонов проектирования»[1] описано 9 таких шаблонов: каждый помогает решить некоторую проблему, возникающую как в объектно-ориентированном анализе, так и в практически любом проекте по разработке программного обеспечения. Таким образом, шаблоны «G.R.A.S.P.» — хорошо документированные, стандартизированные и проверенные временем принципы объектно-ориентированного анализа, а не попытка привнести что-то принципиально новое.

Каталог шаблоновПравить

Краткая характеристика девяти шаблонов:

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

Шаблон определяет базовый принцип распределения ответственностей:

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

Этот шаблон — самый очевидный и важный из девяти. Если его не учесть — получится спагетти-код, в котором трудно разобраться.

Локализация же ответственностей, проводимая согласно шаблону:

  • Повышает:
    • Инкапсуляцию;
    • Простоту восприятия;
    • Готовность компонентов к повторному использованию;
  • Снижает:

2. Создатель (Creator)Править

Проблема: Кто отвечает за создание объекта некоторого класса A?

Решение: Назначить классу B обязанность создавать объекты класса A, если класс B:

  • содержит(contains) или агрегирует(aggregate) объекты A;
  • записывает(records) объекты A;
  • активно использует объекты A;
  • обладает данными для инициализации объектов A

Можно сказать, что шаблон «Creator» - это интерпретация шаблона «Information Expert» (смотрите пункт № 1) в контексте создания объектов.

Большинство порождающих шаблонов проектирования так или иначе выводятся или опираются на шаблон «Creator».

3. Контроллер (Controller)Править

  • Отвечает за операции, запросы которые приходят от пользователя, и может выполнять сценарии одного или нескольких вариантов использования (например, создание и удаление);
  • Не выполняет работу самостоятельно, а делегирует компетентным исполнителям;
  • Может представлять собой:
    • Систему в целом;
    • Подсистему;
    • Корневой объект;
    • Устройство.

4. Низкое связывание (Low Coupling)Править

«Степень зацепления» — мера неотрывности элемента от других элементов (либо мера данных, имеющихся у него о них).

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

«Слабое» зацепление — распределение ответственностей и данных, обеспечивающее взаимную независимость классов. Класс со «слабым» зацеплением:

  • Имеет слабую зависимость от других классов;
  • Не зависит от внешних изменений (изменение в одном классе оказывает слабое влияние на другие классы);
  • Прост для повторного использования.

5. Высокая связность (High Cohesion)Править

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

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

Связность класса — мера сфокусированности предметных областей его методов:

  • «Высокая» связность — сфокусированные подсистемы (предметная область определена, управляема и понятна);
  • «Низкая» связность — абстрактные подсистемы, затруднены:
    • Восприятие;
    • Повторное использование;
    • Поддержка;
    • Устойчивость к внешним изменениям.

6. Полиморфизм (Polymorphism)Править

Устройство и поведение системы:

Пример: Адаптация коммерческой системы к многообразию систем учёта налогов может быть обеспечена через внешний интерфейс объектов-адаптеров (см. также: Шаблон «Адаптеры»).

7. Чистая выдумка (Pure Fabrication)Править

Не относится к предметной области, но:

«Pure Fabrication» отражает концепцию сервисов в модели предметно-ориентированного проектирования.

Пример задачи: Не используя средства класса «А», внести его объекты в базу данных.

Решение: Создать класс «Б» для записи объектов класса «А» (см. также: «Data Access Object»).

8. Перенаправление (Indirection)Править

Слабое зацепление между элементами системы (и возможность повторного использования) обеспечивается назначением промежуточного объекта их посредником.

Пример: В архитектуре Model-View-Controller, контроллер (англ. controller) ослабляет зацепление данных (англ. model) с их представлением (англ. view).

9. Устойчивость к изменениям (Protected Variations)Править

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

См. такжеПравить

СсылкиПравить

  1. Larman, Craig. Applying UML and Patterns — Third Edition. [1] Архивная копия от 30 июня 2003 на Wayback Machine