GRASP

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

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

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

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

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

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

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

Возможно, этот шаблон является самым очевидным из девяти, но вместе с тем и самым важным.

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

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

Шаблон определяет, кто должен создавать объект (фактически, это применение шаблона «Информационный эксперт» к проблеме создания объектов): целесообразно назначить классу «B» обязанность создавать экземпляры класса «A», если «B» производит следующие действия по отношению к «A»:

  • Содержит или агрегирует;
  • Записывает;
  • Активно использует;
  • Обладает данными инициализации.

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

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

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

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

Low coupling (Слабое зацепление)[править | править вики-текст]

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

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

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

High cohesion (Высокая степень связанности)[править | править вики-текст]

«Степень связанности» — это мера «сфокусированности» обязанностей класса и «схожести» предметной области методов класса; методы разных предметных областей лучше разделить на классы.

Высокая степень связанности — это принцип, который задаёт свойство высокой взаимосвязи внутри подсистемы: классы не берут на себя обязанности из разных предметных областей и получаются «сфокусированными» (управляемыми и понятными).

Классы с «низкой» степенью связанности[править | править вики-текст]

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

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

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

Polymorphism (Полиморфизм)[править | править вики-текст]

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

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

Pure fabrication (Чистая выдумка)[править | править вики-текст]

«Чистая выдумка» — это класс, который не отражает никакого реального объекта предметной области, но специально используется для достижения каких-либо из следующих целей:

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

Пример: Есть класс «A», объекты которого нужно записать в базу данных и которым нельзя позволить самостоятельно «лезть» в неё (т.к. это приведёт к слабой связности внутри класса «A»). Тогда мы создаём специальный класс «B» (например, с именем «MyClassDAO» или «MyClassRepository»), который будет иметь сильную связность внутри и единую ответственность: записывать объекты класса «A» в базу данных.

Indirection (Посредник)[править | править вики-текст]

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

Пример: Метод model-view-controller, который позволяет ослабить связь между данными (model) и их представлением (view) с помощью введения контроллера (т.е. «класса-посредника», отвечающего за поведение).

Protected variations (Устойчивый к изменениям)[править | править вики-текст]

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

См. также[править | править вики-текст]

Ссылки[править | править вики-текст]

  1. Larman, Craig. Applying UML and Patterns — Third Edition. [1]
  2. Макконнелл, Стив. Совершенный код мастер-класс = Code Complete. — 2-е издание. — Русская редакция, 2014. — С. 139. — 1 с. — ISBN 978-5-7502-0064-1.