GRASP (объектно-ориентированное проектирование)

Общие шаблоны программного обеспечения для распределения ответственности (или принципы ), сокращенно GRASP , представляют собой набор «девяти фундаментальных принципов проектирования объектов и распределения ответственности». ^[1]^: 6 впервые опубликовано Крейгом Ларманом в 1997 году. ^{[ нужна ссылка ]} книга «Применение UML и шаблонов» .

В GRASP используются различные шаблоны и принципы: контроллер, создатель, косвенность, эксперт по информации, низкая связанность , высокая связность , полиморфизм , защищенные вариации и чистое производство. ^[2] Все эти шаблоны решают некоторые проблемы программного обеспечения, общие для многих разработки программного обеспечения проектов . Эти методы были изобретены не для создания новых способов работы, а для лучшего документирования и стандартизации старых, проверенных принципов программирования в объектно-ориентированном проектировании.

Ларман утверждает, что «важнейшим инструментом проектирования для разработки программного обеспечения является разум, хорошо разбирающийся в принципах проектирования. Это не UML или какая-либо другая технология». ^[3]^: 272 Таким образом, принципы GRASP на самом деле представляют собой набор умственных инструментов, учебное пособие, помогающее проектировать объектно-ориентированное программное обеспечение.

Узоры

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

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

Проблема: Каков основной принцип распределения ответственности за объекты?
Решение: возложите ответственность на класс, у которого есть информация, необходимая для ее выполнения.

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

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

Это приведет к возложению ответственности на класс, обладающий наибольшим количеством информации, необходимой для ее выполнения. ^[3]^: 17:11

Связанный шаблон или принцип : низкая связь, высокая связность.

Создатель

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

Проблема: кто создает объект A?
Решение. В общем, назначьте класс B ответственность за создание объекта A если применимо одно или, предпочтительно, несколько из следующих условий:

Экземпляры B содержать или составным образом агрегировать экземпляры A
Экземпляры B записывать случаи A
Экземпляры B внимательно использовать примеры A
Экземпляры B иметь инициализационную информацию для экземпляров A и передать его созданию. ^[3]^: 16:16.7

Связанный шаблон или принцип : Низкая связь, Заводской шаблон.

Контроллер

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

Проблема: кто должен нести ответственность за обработку событий системы ввода?
Решение. Контроллер вариантов использования должен использоваться для обработки всех системных событий варианта использования и может использоваться более чем для одного варианта использования. Например, для вариантов использования «Создать пользователя» и «Удалить пользователя» можно использовать один класс с именем UserController вместо двух отдельных контроллеров вариантов использования. В качестве альтернативы фасадный контроллер можно использовать ; это применимо, когда объект, отвечающий за обработку события, представляет собой всю систему или корневой объект.

Контроллер определяется как первый объект за пределами уровня пользовательского интерфейса, который получает и координирует («управляет») системную операцию. Контроллер должен делегировать работу, которую необходимо выполнить, другим объектам; он координирует или контролирует деятельность. Он не должен выполнять много работы сам по себе. Контроллер GRASP можно рассматривать как часть уровня приложений/сервисов. ^[4] (при условии, что приложение провело явное различие между уровнем приложения/сервиса и уровнем предметной области ) в объектно-ориентированной системе с общими уровнями в логической архитектуре информационной системы.

Связанный шаблон или принцип : Команда , Фасад , Слои , Чистое производство.

Косвенность

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

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

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

Низкая связь

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

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

Высокая сплоченность

Высокая сплоченность — это оценочный шаблон, который пытается сохранить объекты должным образом сфокусированными, управляемыми и понятными. Высокая связность обычно используется в поддержку низкой связанности. Высокая сплоченность означает, что обязанности данного набора элементов тесно связаны между собой и сосредоточены на довольно конкретной теме. Разбиение программы на классы и подсистемы, если оно выполнено правильно, является примером действий, которые повышают связующие свойства именованных классов и подсистем. Альтернативно, низкая сплоченность — это ситуация, в которой набор элементов, например подсистема, имеет слишком много несвязанных между собой обязанностей. Подсистемы с низкой связностью между составляющими их элементами часто страдают от того, что их трудно понять, повторно использовать, поддерживать и изменять в целом. ^[3]^{: 314–315}

Полиморфизм

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

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

Защищенные варианты

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

Проблема: как спроектировать объекты, подсистемы и системы так, чтобы изменения или нестабильность этих элементов не оказывали нежелательного влияния на другие элементы?
Решение: Определить точки прогнозируемого отклонения или нестабильности; распределите обязанности, чтобы создать вокруг них стабильный интерфейс.

Чистая выдумка

Чистое производство — это класс, который не представляет концепцию в проблемной области, специально созданный для достижения низкой связанности, высокой связности и полученного из этого потенциала повторного использования (когда решение, представленное шаблоном информационного эксперта, этого не делает). Этот вид класса называется «сервисом» в предметно-ориентированном проектировании .

Связанные шаблоны и принципы • Низкая связь.• Высокая сплоченность.

См. также

Ссылки

^ Крейг Ларман (2001). Применение UML и шаблонов: введение в объектно-ориентированный анализ, проектирование и унифицированный процесс (PDF) (2-е изд.). Прентис Холл. ISBN 0-13-092569-1 .
^ Мухаммад Умайр (26 февраля 2018 г.). «SOLID, GRASP и другие основные принципы объектно-ориентированного проектирования» . ДЗона .
^ Jump up to: ^а ^б ^с ^д Крейг Ларман (2004). Применение UML и шаблонов: введение в объектно-ориентированный анализ, проектирование и итеративную разработку (3-е изд.). Пирсон. ISBN 978-0131489066 .
^ «Уровень приложений похож на бизнес-фасад?» . Yahoo! Группы (доменный дизайн) . Архивировано из оригинала 07 августа 2020 г. Проверено 15 июля 2010 г.

[Larman2001-1] Крейг Ларман (2001). Применение UML и шаблонов: введение в объектно-ориентированный анализ, проектирование и унифицированный процесс (PDF) (2-е изд.). Прентис Холл. ISBN 0-13-092569-1 .

[Umair2018-2] Мухаммад Умайр (26 февраля 2018 г.). «SOLID, GRASP и другие основные принципы объектно-ориентированного проектирования» . ДЗона .

[Larman2004-3] Jump up to: ^а ^б ^с ^д Крейг Ларман (2004). Применение UML и шаблонов: введение в объектно-ориентированный анализ, проектирование и итеративную разработку (3-е изд.). Пирсон. ISBN 978-0131489066 .

[Yahoo-4] «Уровень приложений похож на бизнес-фасад?» . Yahoo! Группы (доменный дизайн) . Архивировано из оригинала 07 августа 2020 г. Проверено 15 июля 2010 г.

[1]

[2]

[3]

[4]