Шаблоны проектирования GRASP.

Шаблоны объектно-ориентированного проектирования GRASP February 8th, 2009

Current Mood: creative

На одном собеседовании меня спросили: "знаете ли Вы, что такой GRASP?". К своему стыду, я даже понятия не имел, что эта аббревиатура означает. Потом, все же, человек, проводивший интервью сознался, что этот вопрос был со звездочкой и ответ на него был не обязателен. И действительно, у каждого специалиста свои тараканы в голове и разобраться с каждой имеющейся аббревиатуре почти нереально и все же, после того, как я все-таки посмотрел, что такое GRASP, меня охватил еще больший стыд, как оказалось название GRASP объединяет фундаментальные принципы, положенные в основу объектно-ориентированного проектирования. Принципы эти на интуитивном уровне известны каждому разработчику, хоть раз прикасавшемуся к ООП, однако их систематическое именование и повторное использование в виде шаблонов оставалось за рамками трансцендентного процесса проектирования ПО. Настала пора снять завесу тайны и назвать вещи своими именами.

GRASP - General Responsibility Assignment Software Patterns (основные шаблоны распределения обязанностей в программном обеспечении). Это методический подход к объектному проектированию. Эти шаблоны называют также шаблонами распределения обязанностей. Под "шаблоном" в данном контексте, да и в любом контексте, связанном с разработкой ПО, понимается именованная пара "проблема/решение", содержащая рекомендации для применения в различных конкретных ситуациях. Шаблоны GRASP относятся к этапу проектирования и отвечают за взаимосвязь объектов в системе. GRASP состоит из 5 основных и 4 дополнительных шаблонов.

Основные шаблоны:

Information Expert

Дополнительные шаблоны:

Pure Fabrication

• Protected Variations

Information Expert

Шаблон решает проблему распределения обязанностей между объектами в объектно-ориентированной системе. Под обязанностью в контексте GRASP понимается некое действие (функция) объекта. Т.о. Information Expert дает рекомендации касательно того, какие функции должен выполнять тот или иной объект. А решение очень простое и понятное без доказательств: назначать обязанность следует информационному эксперту - классу, у которого имеется информация, требуемая для выполнения обязанности. Конечно, не всегда бывает так, что вся необходимая информация заключена в одном классе (это, кстати, идет в противоречие с паттерном High Cohesion, о котором позже), чаще она распределена между различными классами, тогда каждый из этих классов будет являться частичным экспертом, т.е. будет предоставлять только доступную ему информацию, а при общем взаимодействии будет решена общая задача.

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

Класс B агрегирует (aggregate) объекты A

Класс B содержит (contains) объекты A

Класс B записывает (records) экземпляры объектов A

Класс B активно использует (closely uses) объекты A

Класс B обладает данными инициализации (has the initializing data), которые будут передаваться объектам A при их создании (т.е. при создании объектов А класс В является экспертом)

Смысл паттерна снова интуитивно понятен, каждый разработчик использовал его, руководствуясь здравой логикой, сам того не осознавая. Тем не менее, за кажущейся простотой скрывается масса преимуществ: поддерживается шаблон Low Coupling, снижаются затрат на сопровождение и обеспечивается возможности повторного использования созданных компонентов в дальнейшем.

Controller

Шаблон сontroller решает давнюю проблему разделения интерфейса и логики в интерактивном приложении. Это не что иное, как C из аббревиатуры MVC. Этот шаблон отвечает за то, к кому именно должны обращаться вызовы из V (View), и кому C должен делегировать запросы на выполнение (какая модель M должна их обработать). Если обобщить назначение сontroller, то он должен отвечать за обработку входных системных сообщений. Под системными сообщениями здесь понимаются события высокого уровня, генерируемые внешним исполнителем. Чтобы решить поставленную проблему необходимо делегировать обязанности обработки системных сообщений классу, удовлетворяющему одному из следующих условий:

Класс представляет всю систему в целом, устройство или подсистему (внешний контроллер)

Класс представляет сценарий некоторого прецедента, в рамках которого выполняется обработка всех системных событий, и обычно называется <Прецедент>Handler, <Прецедент>Coordinator или <Прецедент>Session (контроллер прецедента или контроллер сеанса). Для всех системных событий в рамках одного сценария прецедента используется один и тот же класс-контроллер. Неформально, сеанс - это экземпляр взаимодействия с исполнителем. Сеансы могут иметь произвольную длину, но зачастую организованы в рамках одного прецедента (сеанса прецедента).

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

Low Coupling

Шаблон решает проблему связности. Связность можно определить как количество точек соприкосновения классов между собой. Известно, что чем ниже связность классов, тем меньше их взаимовлияние, тем выше возможность повторного использования. А рекомендация здесь простая: распределять обязанности между классами надо таким образом, чтобы уменьшить связность.

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

Высокая степень связывания сама по себе не является проблемой. Проблемой является жесткое связывание с неустойчивыми в некотором отношении элементами.

High Cohesion

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

High Cohesion твердит, что класс должен стараться выполнять как можно меньше не специфичных для него задач, и иметь вполне определенную область применения. Только с опытом приходит понимание балансировки между High Cohesion и Low Coupling. считается что связывание и зацепление это инь и янь проектирования ПО. Некорректное связывание порождает неправильное зацепление и наоборот.

Pure Fabrication

Формулировки и мотивации дополнительных шаблонов GRASP не так очевидны. И без примеров здесь трудно ориентироваться. Проблемой, решаемой Pure Fabrication, является обеспечение реализации шаблонов High Cohesion и Low Coupling или других принципов проектирования, если шаблон Expert (например) не обеспечивает подходящего решения. Решением может быть введение служебного класса, не представляющего понятия конкретной предметной области, однако имеющего высокую степень зацепления.

Например, классу X необходимо сохранять информацию в реляционной базе данных. Согласно шаблону Information Expert, эту обязанность можно присвоить самому классу X. Однако следует принять во внимание, что Данная задача требует достаточно большого числа специализированных операций, поэтому класс X будет иметь низкую степень зацепления, класс X будет связан с интерфейсом БД, что повысит связность, кроме того задача записи в БД является довольно общей, поэтому необходимо обеспечить повторное использование кода. Естественным решением данной проблемы является создание нового класса, ответственного за сохранение объектов некоторого вида на постоянном носителе, например в реляционной базе данных. Его можно назвать PersistentStorage. Это чисто синтетический объект, что полностью соответствует Pure Fabrication. В итоге решаются задачи зацепления, связности и повторного использования.

Indirection

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

Пример, рассмотренный выше, с введением класса PersistentStorage является также и примером шаблона Indirection, т.к. дополнительный класс будет являться промежуточным звеном между БД и классом X. Примерами специализированных вариантов Indirection являются шаблоны Adapter, Facade, Observer (см. шаблоны Gang of Four). Целью введения промежуточного звена является обеспечение слабой связности за счет отделения друг от друга различных компонентов.

Polymorphism

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

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

Новые вариации можно вводить без модификации клиентской части приложения.

Protected Variations

Основная проблема, решаемая шаблоном Protected Variations: как спроектировать объекты, подсистемы и систему, чтобы изменение этих элементов не оказывало нежелательного влияния на другие элементы? необходимо идентифицировать точки возможных вариаций или неустойчивости; распределить обязанности таким образом, чтобы обеспечить устойчивый интерфейс. Шаблон PV описывает ключевой принцип, на основе которого реализуются механизмы и шаблоны программирования и проектирования с целью обеспечения гибкости и защиты системы от влияния изменений внешних систем.

Про принципы SOLID в сети есть много информации. В каких-то местах – она заумная до ужаса, в каких-то – описано понятным человеческим языком. Почему-то, в последнее время я не могу терпеть слишком заумных объяснений. На поверку дня убеждаюсь, что человек, который действительно знает о чем говорит, всегда может объяснить вещи “человеческим” или более понятным языком, чем принято в кандидатских работах.
Но про принципы GRASP написано немного, а многое из того что написано – отравляет понимание своей заумностью. Конечно вопрос не из простых. Но и сложность тоже не космическая.
Итак, пункт первый – зачем эти принципы?
Объектно-ориентированное программирование (ООП) – я бы сказал, что это набор основных концепций (абстракция, инкапсуляция, наследование, полиморфизм), конструкций (классы, методы) и принципов. ООП – это модель, обобщенная модель части предметной или объектной области для программирования окружающего. Это программирование по обобщенной модели, выражение объектной модели в терминах языка программирования. И модель эта, как и любая другая модель, - осознано ограничена.
Так вот, громадной частью ООП является набор принципов. И тут вроде бы все ясно. Только вот принципов много. И разные авторы выделяют как основные иногда схожие, а иногда и разные принципы, и что удивительно – все правильные.
Моделировать – не сложно. Только проблема в том что мы все таки имеем дело с моделью. А когда объекты (сущности) уже созданы, тогда вступает в игру именно программирование и проектирование. Объекты должны взаимодействовать и при этом модель должна быть гибкой и простой. Вот тут нам и помогают принципы.
GRASP – это набор принципов по версии такого эксперта как Крэг Ларман , который написал о них в своей книге - Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development

Кстати, книга есть в переводе на русский . Книга как и книга GoF(Gang of four) заняла свое место в истории и соответственно принципы GRASP, которым посвящена малая часть книги тоже.
Возможно, они не так популярны как скажем принципы SOLID, скорее всего, мне кажется, потому что они определенны более обобщенными. Эти принципы более абстрактные чем шаблоны GoF или SOLID.
Итак принципы GRASP, точнее сказать не принципы, а шаблоны в оригинале. General Responsibility Assignment Software Patterns – это можно перевести так – паттерны распределения ответственности. Суть в том, что это не строгие паттерны как у GoF, это скорее тот смысл, которым мы наделяем объекты. Так что принципы распределения общей ответственности подходит больше чем паттерны. И поэтому название статьи не шаблоны GRASP как было бы идеологически верно, а все таки принципы GRASP.
GRASP выделяет следующие принципы-шаблоны:

• Information Expert (Информационные эксперт)
• Creator (Создатель)
• Controller (Контроллер)
• Low Coupling (Слабая связанность)
• High Cohesion (Высокая сцепленность)
• Pure Fabrication (Чистая выдумка или чистое синтезирование)
• Indirection (Посредник)
• Protected Variations (Сокрытие реализации или защищенные изменения)
• Polymorphism(Полиморфизм)

Опытные разработчики объектно-ориентированных систем сформулировали об­щие принципы истандартные решения , помогающие в разработке программного обеспечения. Если эти принципы и идиомы систематизировать и структуриро­вать, а также присвоить им имена, то их можно применять в качествешаблонов (patterns).

Приведем пример одного из таких шаблонов:

В объектно-ориентированной технологии проектирования шаблоном назы­вают именованное описание проблемы и ее решения, которые можно применить при разработке других систем. (Другими словами, шаблон – это именованная пара "проблема/решение ", содер­жащая рекомендации для применения в различных конкретных ситуациях, которую можно использовать в различных контекстах.)

Имена шаблонов

Именование шаблонов, методов и принципов имеет следующие преимущества:

Позволяет зафиксировать понятие в памяти;

Облегчает общение.

В частности, шаблоны GRASPимеют осмыс­ленные имена, например,Information Expert (Эксперт),Creator (Создатель),Pro ­ tected Variations (Защищенные вариации).

Если шаблон имеет имя, то его легко обсуждать с другими разработчиками. Использование общеизвестных имен не только облегчает общение, но и позволяет обсуж­дать вопросы разработки на более высоком уровне абстракции.

Применение шаблонов GRASP

Ниже приводится описание основных пяти шаблонов GRASP:

• Information Expert

• High Cohesion

  Low Coupling

  Controller

Применение этих шаблонов касается основных и фундаментальных вопросов проектирования.

Система обозначений диаграммы классов в языке UML

Диаграммы классов иллюстрируют взаимоотношения программных элементов. Обозначение класса состоит из трех частей, в которых указываются имя класса, его атрибуты и методы (рис. 2.1).

Рисунок 2.1 – Имена методов программных классов

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

Шаблон Information Expert

Решение. Назначить обязанность информационному эксперту – классу, у ко­торого имеется информация, требуемая для выполнения обязанности.

Проблема. Каков наиболее общий принцип распределения обязанностей меж­ду объектами при объектно-ориентированном проектировании?

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

Пример . В приложении POS-системы ТТ некоторому классу необходимо знать общую сумму продажи.

Начинать распределение обязанностей следует с их четкой формулировки.

С этой точки зрения можно сформулировать следующее утверждение: Какой класс должен отвечать за знание общей суммы продажи?

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

Теперь возникает ключевой вопрос: на основе какой модели нужно анали­зировать информацию – модели предметной области или проектирования? Мо­дель предметной области иллюстрирует концептуальные классы из предметной области системы, а в модели проектирования показаны программные классы.

Ответ на этот вопрос сводится к следующему:

если в модели проектирования имеются соответствующие классы, в пер­вую очередь, следует использовать ее;

в противном случае нужно обратиться к модели предметной области и постараться уточнить ее для облегчения создания соответствующих про­граммных классов.

Например , предположим, мы находимся в самом начале этапа проектирова­ния, когда модель проектирования представлена в минимальном объеме. Следо­вательно, кандидатуру на роль информационного эксперта следует искать в мо­дели предметной области. Вероятно, на эту роль подойдет концептуальный классSale. Тогда в модель проектирования нужно добавить соответствующий про­граммный класс под именемSaleи присвоить ему обязанность вычисления об­щей стоимости, реализуемую с помощью вызова методаgetTotal. При таком подходе сокращается разрыв между организацией программных объектов и со­ответствующих им понятий из предметной области.

Чтобы рассмотреть этот пример подробнее, обратимся к фрагменту модели предметной области, представленному на рис. 2.2:

Рисунок 2.2 – Ассоциации объекта Sale

Какая информация требуется для вычисления общей суммы? Необходимо узнать стоимость всех проданных товаровSalesLineItemи просуммировать эти промежуточные суммы. Такой информацией обладает лишь экземпляр объект,Sale. Следовательно, с точки зрения шаблонаInformationExpertобъектSaleподходит для выполнения этой обязанности, т.е. являетсяинформационным экспертом (informationexpert).

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

Рисунок 2.3 – Фрагмент диаграммы взаимодействий

Однако на данном этапе выполнена не вся работа. Какая информация тре­буется для вычисления промежуточной суммы элементов продажи? Необходимы значения атрибутов SalesLineItem.quantityиSalesLineItem.price. Объек­туSalesLineItemизвестно количество товара и известен связанный с ним объ­ектProductSpecification. Следовательно, в соответствии с шаблономExpert, промежуточную сумму должен вычислять объект SalesLineItem. Другими сло­вами, этот объект являетсяинформационным экспертом.

В терминах диаграмм взаимодействий это означает, что объект Saleдолжен передать сообщенияgetSubtotalкаждому объекту SalesLineItem, а затем про­суммировать полученные результаты. Этот процесс проиллюстрирован на рис. 2.4:

Рисунок 2.4 – Вычисление общей суммы продажи

Для выполнения обязанности, связанной со знанием и предоставлением промежуточной суммы, объекту SalesLineItem должна быть известна стои­мость товара.

В данном случае в качестве информационного эксперта будет выступать объект ProductSpecification.

Результаты проектирования представлены на рис. 2.5:

Рисунок 2.5 – Вычисление общей суммы продажи

Для выполнения обязанности "знать и предоставлять общую сумму продажи трем объектам классов" были следующим образом присвоены три обязанности.

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

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

Преимущества

Шаблон Expertподдерживает инкапсуляцию. Для выполнения требуемых задач объекты используют собственные данные. Подобную возможность обеспечивает также шаблонLowCoupling, применение которого приводит к созданию более надежных и легко поддерживаемых систем.

Соответствующее поведение системы обеспечивается несколькими классами, содержащими требуемую информацию. Это приводит к определениям клас­сов, которые гораздо проще понимать и поддерживать. Кроме того, поддер­живается шаблон HighCohesion.

Связанные шаблоны:

Другие названия и аналогичные принципы: "Хранение обязанностей вместе с дан­ными", "Кто знает, тот и выполняет", "Сделай сам", "Размещайте службы вме­сте с их атрибутами".

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

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

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

Разные принципы для одинаковых моделей

Так вот, громадной частью ООП является набор принципов — выверенных временем качественных решений и стандартов хорошего тона. И тут вроде бы все ясно. Только вот принципов много. И разные авторы выделяют как основные, иногда схожие, а иногда — и разные принципы, и что удивительно — они разом все правильные.

Да, моделировать — не сложно. Только проблема в том, что мы все-таки имеем дело всего лишь с моделью. А когда объекты (сущности) уже созданы, тогда вступает в игру именно их программирование и проектирование. Объекты должны взаимодействовать, и при этом модель должна быть гибкой, однородной и простой. Вот тут нам и помогают универсальные принципы, которые, повторюсь, во многом близки по смыслу шаблонам.

Основной вопрос на который дает ответ высокая сцепленность — «Как поддерживать объекты сфокусированными на одной ответственности, понятными, управляемыми и как побочный эффект иметь слабо связанный код?»

Их нужно разделять. Подробнее это описано в 17 главе вышеупомянутой книги Лармана .

Pure Fabrication

Pure Fabrication или чистая выдумка , или чистое синтезирование. Здесь суть в выдуманном объекте. Вот такой себе принцип-хак! Но без него никак. Аналогом может быть шаблон Service (сервис) в .

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

Итак — ситуация. Какой класс должен сохранять наш объект Sale в базу данных? Если подчиняется принципу «информационный эксперт », то Sale , но наделив его такой ответственностью мы получаем слабую сцепленность внутри него. Тогда можно найти выход, создав синтетическую сущность — SaleDao или SaleRepository , которая будет сильно сцеплена внутри и будет иметь единую ответственность — и правильно сохранять Sale в базу.

Так как мы выдумали этот объект, а не спроектировали с предметной области, то и он подчиняется принципу «чистая выдумка ».

Indirection

Indirection или посредник . Можно столкнуться с таким вопросом: «Как определить ответственность объекта и избежать сильной связанности между объектами, даже если один класс нуждается в функционале (сервисах), который предоставляет другой класс?» Необходимо наделить ответственностью объект посредник.

Например, возвратимся опять же MVC. UI-логике на самом деле нужен не контроллер, а модель, доменная логика. Но мы не хотим? чтобы UI-логика была сильно связанна с моделью, и возможно в UI мы хотим получать данные и работать с разной предметной логикой. А связывать UI-слой с бизнес логикой было бы глупо, потому что получим код который будет сложный для изменений и поддержки. Выход — вводим контроллер как посредник между View и Model.

Так что распределяйте ответственности всем своим объектам ответственно (с умом).

Protected Variations

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

Кажется мы такое обсуждали уже. И пришли к выводу, что нужно использовать low coupling или dependency injection . Именно! Но суть текущего принципа немного в другом. Суть в том, чтобы определить «точки изменений» и зафиксировать их в абстракции (интерфейсе). «Точки изменений» — не что иное, как наши объекты, которые могут меняться.

То есть суть этого принципа в том, чтобы определить места в системе, где поведение может изменится и выделить абстракцию, на основе которой и будет происходить дальнейшее программирование с использованием этого объекта

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

Polymorphism

Polymorphism или полиморфизм . Тоже знакомо, не так ли? Так вот это об том же полиморфизме, который мы знаем из ООП. Если заметить, то достаточно много , да и вообще паттернов, построено на полиморфизме. Что он дает? Он дает возможность трактовать однообразно разные объекты с одинаковым интерфейсом (спецификацией). Давайте вспомним такие паттерны как Strategy , Chain of Resposibility , Command ... — их много ещё всяких. И все по своей сути основываются на полиморфизме.

Полиморфизм решает проблему обработки альтернативных вариантов поведения на основе типа. Яркий пример этого — шаблон из GoF, — Strategy (Стратегия).

Например, для реализации гибкого функционала для шифрования можно определить интерфейс IEncryptionAlgorithm с методом Encrypt , и объект создатель , который вернет IEncryptionAlgorithm , создав внутри себя актуальную реализацию этого интерфейса.

Явно или неясно, пользуясь другими принципами или шаблонами — мы тоже часто используем принципы или при разработке и проектировании. Многие принципы пересекаются, просто возможно разные авторы по-разному смещают акценты, но на удивление все принципы и шаблоны верны — и SOLID , и GRASP и классические — и многие другие. И все их следует использовать с умом и балансировать ними, применяя совместно с какими-то хаками под свою систему, что позволяет разрабатывать действительно красивые, устойчивые и гибкие архитектуры и приложения.

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

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

И как всегда в заключение, даю наводки на дополнительные материалы по рассмотренной сегодня теме:

Также для закрепления темы хорошая презентация на русском.

Шаблоны проектирования GRASP

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

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

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

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

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

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

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

Creator (Производитель)

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

• Класс B содержит (contains) или агрегирует (aggregate) объекты A.
• Класс B записывает (records) экземпляры объектов A.
• Класс B активно использует (closely uses) объекты A
• Класс B обладает данными инициализации (has the initializing data) для объектов A.

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

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

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

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

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

Low Coupling - это оценочный образец (или принцип), который устанавливает следующие свойства:

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

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

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

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

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

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

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

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

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

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

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

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

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