Interested Article - GRASP

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

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

Каталог шаблонов

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

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 . от 30 июня 2003 на Wayback Machine
  2. . Дата обращения: 1 ноября 2021. 31 марта 2022 года.
Источник —

Same as GRASP