GRASP

Материал из Википедии — свободной энциклопедии
Перейти к: навигация, поиск

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

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

Каталог шаблонов[править | править вики-текст]

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

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

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

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

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

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

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

2. Создатель (Creator)[править | править вики-текст]

Класс должен создавать экземпляры тех классов, которые он может:

  • Содержать или агрегировать;
  • Записывать;
  • Использовать;
  • Инициализировать, имея нужные данные.

Так применяется шаблон «Информационный эксперт» (смотрите пункт №1) в вопросах создания объектов.

Альтернатива — шаблон «Фабрика» (создание объектов концентрируется в отдельном классе).

3. Контроллер (Controller)[править | править вики-текст]

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

4. Слабая степень связности (Low Coupling)[править | править вики-текст]

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

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

  • Не зависит от внешних изменений;
  • Прост для повторного использования.

5. Высокое зацепление (High Cohesion)[2][править | править вики-текст]

Предметные области следует разделять по классам.

Зацепление класса — мера подобия предметных областей его методов:

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

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]