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

[непроверенная версия]

[отпатрулированная версия]

Содержимое удалено Содержимое добавлено

Линейный

Текущая версия от 04:19, 29 октября 2023

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

В книге Крэга Лармана «Применение UML и шаблонов проектирования»^[1] описано 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)

Зацепление — мера того, насколько взаимозависимы разные подпрограммы или модули^[2].

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

5. Сильная (высокая) связность (High Cohesion)

Связность — мера силы взаимосвязанности элементов внутри модуля; способ и степень, в которой задачи, выполняемые некоторым программным модулем, связаны друг с другом^[2].

Сильная связность класса / модуля означает, что его элементы тесно связаны и сфокусированы.

Слабая (низкая) связность класса / модуля означает, что он не сфокусирован на одной цели, его элементы предназначены для слишком многих несвязанных обязанностей. Такой модуль трудно понять, использовать и поддерживать.

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

Устройство и поведение системы:

Определяется данными;
Задано полиморфными операциями её интерфейса.

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

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

Не относится к предметной области, но:

Уменьшает зацепление;
Повышает связность;
Упрощает повторное использование.

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

Пример задачи: Не используя средства класса «А», внести его объекты в базу данных.

Решение: Создать класс «Б» для записи объектов класса «А» (см. также: «Data Access Object»).

8. Перенаправление (Indirection)

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

Пример: В архитектуре Model-View-Controller, контроллер (англ. controller) ослабляет зацепление данных (англ. model) с их представлением (англ. view).

9. Устойчивость к изменениям (Protected Variations)

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

См. также

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

Примечания

↑ Larman, Craig. Applying UML and Patterns — Third Edition. [1] Архивная копия от 30 июня 2003 на Wayback Machine
↑ ¹ ² ISO/IEC/IEEE 24765-2017 Systems and software engineering — Vocabulary (неопр.). Дата обращения: 1 ноября 2021. Архивировано 31 марта 2022 года.

[larman-1] Larman, Craig. Applying UML and Patterns — Third Edition. [1] Архивная копия от 30 июня 2003 на Wayback Machine

[ISO_24765-2] ¹ ² ISO/IEC/IEEE 24765-2017 Systems and software engineering — Vocabulary (неопр.). Дата обращения: 1 ноября 2021. Архивировано 31 марта 2022 года.

[1]

[2]

@@ Строка 1: / Строка 1: @@
-'''GRASP''' ({{lang-en|general responsibility assignment software patterns}} — общие шаблоны распределения ответственностей; также существует английское слово ''"grasp" — «контроль, хватка»'') — шаблоны, используемые в [[Объектно-ориентированное проектирование|объектно-ориентированном проектировании]] для решения общих задач по назначению ответственностей [[Класс (программирование)|классам]] и [[Объект (программирование)|объектам]].
+'''GRASP''' (от {{lang-en|General Responsibility Assignment Software Patterns}} — общие шаблоны распределения ответственностей; также отсылает к {{lang-en|grasp}} — «способность быстрого восприятия, понимание, схватывание») — [[Шаблон проектирования|шаблоны]], используемые в [[Объектно-ориентированное проектирование|объектно-ориентированном проектировании]] для решения общих задач по назначению ответственностей [[Класс (программирование)|классам]] и [[Объект (программирование)|объектам]].
-В книге [[Ларман, Крэг|Крэга Лармана]] «''Применение [[UML]] и шаблонов проектирования''»<ref name="larman">[[:en:Craig Larman|Larman, Craig]]. ''Applying UML and Patterns — Third Edition''. [http://authors.phptr.com/larman/uml_ooad/index.html]</ref> описано 9 таких шаблонов: каждый помогает решить некоторую проблему, возникающую как в [[Объектно-ориентированный анализ|объектно-ориентированном анализе]], так и в практически любом проекте по разработке [[Программное обеспечение|программного обеспечения]]. Таким образом, шаблоны «G.R.A.S.P.» — хорошо документированные, стандартизированные и проверенные временем принципы [[Объектно-ориентированное проектирование|объектно-ориентированного анализа]], а не попытка привнести что-то принципиально новое.
+В книге [[Ларман, Крэг|Крэга Лармана]] «Применение [[UML]] и шаблонов проектирования»<ref name="larman">[[Ларман, Крэг|Larman, Craig]]. ''Applying UML and Patterns — Third Edition''. [http://authors.phptr.com/larman/uml_ooad/index.html] {{Wayback|url=http://authors.phptr.com/larman/uml_ooad/index.html|date=20030630201405}}</ref> описано 9 таких шаблонов: каждый помогает решить некоторую проблему, возникающую как в [[Объектно-ориентированный анализ|объектно-ориентированном анализе]], так и в практически любом проекте по разработке [[Программное обеспечение|программного обеспечения]]. Таким образом, шаблоны «GRASP» — хорошо документированные, стандартизированные и проверенные временем принципы объектно-ориентированного анализа, а не попытка привнести что-то принципиально новое.
 == Каталог шаблонов ==
 Краткая характеристика девяти шаблонов:
-===  1. Информационный эксперт (Information Expert) ===
+=== 1. Информационный эксперт (Information Expert) ===
-Шаблон определяет базовый принцип распределения ответственностей:  <blockquote>''Ответственность должна быть назначена тому, кто владеет максимумом необходимой информации для исполнения —'' '''информационному эксперту'''.</blockquote>Этот шаблон — самый очевидный и важный из девяти. Если его не учесть — получится [[спагетти-код]], в котором трудно разобраться.
+Шаблон определяет базовый принцип распределения ответственностей. Обязанности должны быть назначены объекту, который владеет максимумом необходимой информации для выполнения обязанности. Такой объект называется ''информационным экспертом''.
+Этот шаблон — самый очевидный и важный из девяти. Если его не учесть — получится [[спагетти-код]], в котором трудно разобраться.
 Локализация же ответственностей, проводимая согласно шаблону:
@@ Строка 13: / Строка 15: @@
 ** [[Инкапсуляция (программирование)|Инкапсуляцию]];
 ** Простоту восприятия;
 ** Готовность компонентов к повторному использованию;
 * Снижает:
 ** степень [[Зацепление (программирование)|зацепления]].
 === 2. Создатель (Creator) ===
+'''Проблема:''' Кто отвечает за создание объекта некоторого класса A?
-{{см. также|Абстрактная фабрика (шаблон проектирования)}}
-Класс должен создавать экземпляры тех классов, которые он может:
-* Содержать или [[Агрегирование (программирование)|агрегировать]];
-* Записывать;
-* Использовать;
-* Инициализировать, имея нужные данные.
+'''Решение:''' Назначить классу B обязанность создавать объекты класса A, если класс B:
-Так применяется шаблон «''Информационный эксперт''» (смотрите пункт №1) в вопросах создания объектов.
+* содержит(contains) или [[Агрегирование (программирование)|агрегирует(aggregate)]] объекты A;
+* записывает(records) объекты A;
+* активно использует объекты A;
+* обладает данными для инициализации объектов A
+Можно сказать, что шаблон «''Creator''» — это интерпретация шаблона «''Information Expert''» (смотрите пункт № 1) в контексте создания объектов.
-Альтернатива — шаблон «[[Абстрактная фабрика (шаблон проектирования)|Фабрика]]» (создание объектов концентрируется в отдельном классе).
+Большинство [[Порождающие шаблоны проектирования|порождающих шаблонов проектирования]] так или иначе выводятся или опираются на шаблон «''Creator''».
-===  3. Контроллер (Controller) ===
-* Отвечает за операции, запросы на которые приходят от пользователя, и может выполнять сценарии одного или нескольких [[Прецедент (UML)|вариантов использования]] (например, создание и удаление);
+=== 3. Контроллер (Controller) ===
+* Отвечает за операции, запросы которых приходят от пользователя, и может выполнять сценарии одного или нескольких [[Прецедент (UML)|вариантов использования]] (например, создание и удаление);
 * Не выполняет работу самостоятельно, а делегирует компетентным исполнителям;
 * Может представлять собой:
 ** Систему в целом;
 ** Подсистему;
 ** Корневой объект;
 ** Устройство.
-=== 4. Слабое зацепление (Low Coupling) ===
+=== 4. Слабое (низкое) зацепление (Low Coupling) ===
-{{См. также|Зацепление (программирование)}}
+{{main|Зацепление (программирование)}}
+Зацепление — мера того, насколько взаимозависимы разные подпрограммы или модули<ref name="ISO_24765">{{Cite web |url=https://standards.iso.org/ittf/PubliclyAvailableStandards/c071952_ISO_IEC_IEEE_24765_2017.zip |title=ISO/IEC/IEEE 24765-2017 Systems and software engineering — Vocabulary |access-date=2021-11-01 |archive-date=2022-03-31 |archive-url=https://web.archive.org/web/20220331214951/https://standards.iso.org/ittf/PubliclyAvailableStandards/c071952_ISO_IEC_IEEE_24765_2017.zip |deadlink=no }}</ref>.
-«'''Степень зацепления»''' — мера ''неотрывности'' элемента от других элементов (либо мера данных, имеющихся у него о них).
-«'''Слабое» зацепление''' является оценочной моделью, которая диктует, как распределить обязанности, которые необходимо поддерживать.
-«'''Слабое» зацепление''' — распределение ответственностей и данных, обеспечивающее взаимную независимость классов. Класс со «слабым» зацеплением:
-* Имеет слабую зависимость от других классов;
-* Не зависит от внешних изменений (изменение в одном классе оказывает слабое влияние на другие классы);
-*Прост для повторного использования.
+Сильное зацепление рассматривается как серьёзный недостаток, поскольку затрудняет понимание логики модулей, их модификацию, автономное тестирование, а также переиспользование по отдельности. Слабое зацепление, напротив, является признаком хорошо структурированной и хорошо спроектированной системы.
-===  5. Высокая связность (High Cohesion) ===
-{{См. также|Связность (программирование)}}
-'''Высокая связность класса''' — это оценочная модель, направленная на удержание объектов должным образом сфокусированными, управляемыми и понятными. Высокая связность обычно используется для поддержания низкого зацепления. Высокая связность означает, что обязанности данного элемента тесно связаны и сфокусированы. Разбиение программ на классы и подсистемы является примером деятельности, которая увеличивает связность системы.
+=== 5. Сильная (высокая) связность (High Cohesion) ===
-И наоборот, низкая связность — это ситуация, при которой данный элемент имеет слишком много несвязанных обязанностей. Элементы с низкой связностью часто страдают от того, что их трудно понять, трудно использовать, трудно поддерживать.
+{{main|Связность (программирование)}}
+Связность — мера силы взаимосвязанности элементов внутри [[Модуль (программирование)|модуля]]; способ и степень, в которой задачи, выполняемые некоторым программным модулем, связаны друг с другом<ref name="ISO_24765"/>.
+Сильная связность класса / модуля означает, что его элементы тесно связаны и сфокусированы.
-'''Связность''' '''класса''' — мера сфокусированности предметных областей его методов:
+Слабая (низкая) связность класса / модуля означает, что он не сфокусирован на одной цели, его элементы предназначены для слишком многих несвязанных обязанностей. Такой модуль трудно понять, использовать и поддерживать.
-* «'''Высокая»''' связность — ''сфокусированные'' подсистемы (предметная область определена, управляема и понятна);
-* «'''Низкая»''' связность — ''абстрактные'' подсистемы затруднены:
-** Восприятие;
-** Повторное использование;
-** Поддержка;
-** Устойчивость к внешним изменениям.
-===  6. Полиморфизм (Polymorphism) ===
+=== 6. Полиморфизм (Polymorphism) ===
 {{См. также|Полиморфизм (информатика)}}
 Устройство и поведение системы:
 * Определяется данными;
 * Задано [[Полиморфизм (программирование)|полиморфными операциями]] её интерфейса.
 '''Пример:''' Адаптация коммерческой системы к ''многообразию'' систем учёта налогов может быть обеспечена через внешний интерфейс объектов-адаптеров (см. также: Шаблон «[[Адаптер (шаблон проектирования)|Адаптеры]]»).
 === 7. Чистая выдумка (Pure Fabrication) ===
 Не относится к [[Предметная область|предметной области]], но:
 * Уменьшает зацепление;
-* Повышает связанность;
+* Повышает связность;
 * Упрощает [[Повторное использование кода|повторное использование]].
-«''Pure Fabrication''» отражает концепцию сервисов в модели [[Проблемно-ориентированное проектирование|проблемно-ориентированного проектирования]].
+«''Pure Fabrication''» отражает концепцию сервисов в модели [[Предметно-ориентированное проектирование|предметно-ориентированного проектирования]].
 '''Пример задачи:''' Не используя средства класса «А», внести его объекты в [[База данных|базу данных]].
-'''Решение:''' Создать класс «Б» для записи объектов класса «А» (см. также: ''«[[Data Access Object|'''Data Access Object''']]''»).
+'''Решение:''' Создать класс «Б» для записи объектов класса «А» (см. также: ''«'''[[Data Access Object]]'''''»).
-=== 8. Посредник (Indirection) ===
+=== 8. Перенаправление (Indirection) ===
 {{см. также|Посредник (шаблон проектирования)}}
 Слабое зацепление между элементами системы (и возможность повторного использования) обеспечивается назначением промежуточного объекта их '''посредником'''.
@@ Строка 89: / Строка 79: @@
 '''Пример:''' В архитектуре [[model-view-controller|Model-View-Controller]], ''контроллер'' ''(англ. controller)'' ослабляет зацепление данных ''(англ. model)'' с их представлением ''(англ. view)''.
-===  9. Устойчивость к изменениям (Protected Variations) ===
+=== 9. Устойчивость к изменениям (Protected Variations) ===
 Шаблон защищает элементы от изменения другими элементами (объектами или подсистемами) с помощью вынесения взаимодействия в фиксированный [[Интерфейс (объектно-ориентированное программирование)|интерфейс]], через который (и только через который) возможно взаимодействие между элементами. Поведение может варьироваться лишь через создание другой реализации интерфейса.
@@ Строка 95: / Строка 85: @@
 * [[Паттерны проектирования]]
-== Ссылки ==
+== Примечания ==
 {{примечания}}

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

Текущая версия от 04:19, 29 октября 2023

Содержание

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

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

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

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

4. Слабое (низкое) зацепление (Low Coupling)

5. Сильная (высокая) связность (High Cohesion)

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

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

8. Перенаправление (Indirection)

9. Устойчивость к изменениям (Protected Variations)

См. также

Примечания

Навигация

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

Текущая версия от 04:19, 29 октября 2023

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

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

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

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

4. Слабое (низкое) зацепление (Low Coupling)

5. Сильная (высокая) связность (High Cohesion)

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

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

8. Перенаправление (Indirection)

9. Устойчивость к изменениям (Protected Variations)

См. также

Примечания

Навигация

Поиск