GRASP: различия между версиями

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску
[непроверенная версия][непроверенная версия]
Содержимое удалено Содержимое добавлено
м оформление
Строка 70: Строка 70:
* Определяется данными;
* Определяется данными;
* Задано [[Полиморфизм (программирование)|полиморфными операциями]] её интерфейса.
* Задано [[Полиморфизм (программирование)|полиморфными операциями]] её интерфейса.
'''Пример:''' Адаптация коммерческой системы к ''многообразию'' систем учёта налогов может быть обеспечена через внешний интерфейс объектов-адаптеров (смотрите также: Шаблон «[[Адаптер (шаблон проектирования)|Адаптеры]]»).
'''Пример:''' Адаптация коммерческой системы к ''многообразию'' систем учёта налогов может быть обеспечена через внешний интерфейс объектов-адаптеров (см. также: Шаблон «[[Адаптер (шаблон проектирования)|Адаптеры]]»).


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

Версия от 04:03, 16 января 2019

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

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

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

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

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

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

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

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

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

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

2. Создатель (Creator)

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

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

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

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

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]