GRASP

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Low Coupling (Низкая связанность)[править | править вики-текст]

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

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

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

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

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

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

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

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

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

Пример

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

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

Чистая выдумка — это класс, не отражающий никакого реального объекта предметной области, но специально придуманный для уменьшения связности, повышения зацепления или увеличения степени повторного использования. Pure Fabrication отражает концепцию сервисов в модели проблемно-ориентированного проектирования. Пример: есть класс, который нужно записать в базу данных. Мы не можем позволить классу изнутри лезть в базу данных, так как это приведёт к слабой связности внутри класса. И мы создаём новый класс с именем «MyClassDao» или «MyClassRepository», который будет иметь сильную связность внутри и единую ответственность записывать объект класса в базу данных

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

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

Пример

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

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

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

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

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

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