GRASP

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

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

Каталог паттернов

Ниже следует краткая характеристика девяти известных паттернов.

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

Шаблон Information Expert определяет базовый принцип назначения обязанностей. Он утверждает, что обязанности должны быть назначены объекту, который владеет максимумом необходимой информации для выполнения обязанности. Такой объект называется информационным экспертом. Возможно, этот шаблон является самым очевидным из девяти, но вместе с тем и самым важным.

Если дизайн не удовлетворяет этому принципу, то при программировании получается спагетти-код, в котором очень трудно разбираться. Локализация обязанностей позволяет повысить уровень инкапсуляции и уменьшить уровень связанности. Кроме читабельности кода повышается уровень готовности компонента к повторному использованию.

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

См. также: Абстрактная фабрика (шаблон проектирования)

Шаблон Creator решает, кто должен создавать объект. Фактически, это применение шаблона Information Expert к проблеме создания объектов. Более конкретно, нужно назначить классу B обязанность создавать экземпляры класса A, если выполняется как можно больше из следующих условий:

• Класс B содержит или агрегирует объекты A.
• Класс B записывает экземпляры объектов A.
• Класс B активно использует объекты A
• Класс B обладает данными инициализации для объектов A.

Альтернативой создателю является шаблон проектирования Фабрика. В этом случае создание объектов концентрируется в отдельном классе.

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

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

Иногда класс-контроллер представляет всю систему в целом, корневой объект, устройство или важную подсистему (внешний контроллер).

Low Coupling (Слабая связанность)

Low Coupling — это принцип, который позволяет распределить обязанности между объектами таким образом, чтобы степень связанности между системами оставалась низкой. Степень связанности (coupling) — это мера, определяющая, насколько жестко один элемент связан с другими элементами, либо каким количеством данных о других элементах он обладает. Элемент с низкой степенью связанности (или слабым связыванием) зависит от не очень большого числа других элементов и имеет следующие свойства:

• Малое число зависимостей между классами (подсистемами).
• Слабая зависимость одного класса (подсистемы) от изменений в другом классе (подсистеме).
• Высокая степень повторного использования подсистем.

High Cohesion (Сильное зацепление)

High Cohesion — это принцип, который задаёт свойство сильного зацепления внутри подсистемы. Классы (подсистемы) таким образом получаются сфокусированными, управляемыми и понятными. Зацепление (cohesion) (или более точно, функциональное зацепление) — это мера связанности и сфокусированности обязанностей класса. Считается что объект (подсистема) обладает высокой степенью зацепления, если его обязанности тесно связаны между собой и он не выполняет огромных объемов работы.

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

• Трудность понимания.
• Сложность при повторном использовании.
• Сложность поддержки.
• Ненадежность, постоянная подверженность изменениям.

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

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

Полиморфизм позволяет обрабатывать альтернативные варианты поведения на основе типа и заменять подключаемые компоненты системы. Обязанности распределяются для различных вариантов поведения с помощью полиморфных операций для этого класса. Все альтернативные реализации приводятся к общему интерфейсу.

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

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

Чистая выдумка — это класс, не отражающий никакого реального объекта предметной области, но специально придуманный для усиления зацепления, ослабления связанности или увеличения степени повторного использования. Pure Fabrication отражает концепцию сервисов в модели Программирование от предметной области.

Indirection (Посредник)

Indirection поддерживает слабую связанность (и возможность повторного использования) путём назначения обязанностей посредника между ними промежуточному объекту. Пример: Model-View-Controller, который позволяет ослабить связь между данными и их представлением с помощью введения класса-посредника (контроллер), отвечающего за поведение.

Protected Variations (Сокрытие реализации)

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

См. также

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

Ссылки

1. ↑ Larman, Craig. Applying UML and Patterns — Third Edition. [1]