Привет, сегодня поговорим про G.R.A.S.P, это шаблоны, которые помогают распределить обязанности между классами и объектами в объектно-ориентированном проектировании. Всего этих шаблонов девять они описаны в книги Крэга Лармана «Применение UML 2.0 и шаблонов проектирования», и лично у меня были большие проблемы с пониманием этих шаблонов.
Дело в том, что при первоначальном знакомстве с этой книгой мне показалось, что предложенные Ларманом вещи абсолютно не совместимы с Agile и более того они мне показались абсолютно непонятными. Я был склонен считать, что это выдумка, которая на практике ничему не применима. Оказалось, что я не прав, позже, когда я занялся именно архитектурой больших приложений, чисто архитектурой и построением распределённых систем мониторинга, я переосмыслил эту книгу, повторно её прочитал и нашёл для себя много интересных идей.
Ключом к переосмыслению было небольшое изменение, классификация тех шаблонов, которые даёт Ларман. Я понял, что эти шаблоны далеко не все одинаковы и они не структурированы так, как например шаблоны «банды четырёх». Это по большому счёту некоторые идеи, которые нужно ещё дополнительно осмыслить. В результате осмысления у меня родилась определённая формула, которую я уже много лет использую и считаю, что гресп на самом деле вполне рабочие шаблоны. И я как раз хотел бы с вами поделиться своим пониманием, возможно оно вам тоже пригодится.
К чему я пришёл, анализируя Лармановские шаблоны? Я пришёл к тому, что на самом деле в них три принципа, одно свойство, и пять ролей. С ролями связанны конкретные обязанности и, по сути, назначение ролей и есть назначение обязанностей. Напомню, что это шаблоны, которые призваны распределять обязанности, это не универсальные шаблоны построения приложения.
Устойчивость к изменениям
В чём была самая большая сложность? Больше всего мне был не понятен шаблон «устойчивость к изменениям» именно его в конечном итоге я вынес как свойство, потому что на самом деле на уровне классов интерфейсов и объектов устойчивость к изменениям определить нельзя проблема в том что устойчивость к изменениям это когда мы вносим изменения в какую-то часть программы и при этом не меняем другие части. В этом смысле это свойство всей программы, то есть нельзя сказать, глядя на класс, глядя на какую-то часть программы устойчива она к изменениям или нет. Более того устойчивость к изменениям — это не бинарный признак, мы можем быть устойчивы к каким-то конкретным изменениям и не быть устойчивы к другим. Устойчивость к изменениям — это глобальное свойство, которое мы должны обеспечить. SOLID, архитектурное проектирование, всё это как раз и направлено на обеспечение устойчивости к изменениям. Поэтому, то, что приводит Ларман, это один из советов по обеспечению этого свойства.
Полиморфизм, низкое зацепление, высокая связность
Далее идут три принципа которые есть практически везде. Речь идёт о шаблоне «полиморфизм», о шаблоне «низкое зацепление», «высокая связность». На самом деле эти шаблоны должны сосуществовать вместе они ен должны применяться раздельно, шаблон полиморфизм говорит нам о том, что мы должны иметь возможность повторно использовать код и делать это через выделение интерфейсов.
Низкое зацепление оно говорит нам о том, что наши классы должны взаимодействовать друг с другом но при этом стримиться уменьшить эти взаимодействия чем меньше дополнительных взаимодействий, связей, тем лучше. Это позволяет их проще переиспользовать, разделять, переносить между частями программы.
Связность это сфокусированность на задаче которые решает класс. Мы говорим о том, что у нас есть принцип единственной ответственности, и когда мы не распыляемся на решение многих задач, и создаём класс для решение конкретных задач, это и есть связность, то есть связность — это мера сосредоточения на конкретной задаче.
5 ролей
Естественно эти принципы мы используем и они являются базовыми, мы должны их придерживаться всегда, а распределение обязанностей, по гресп начинается с момента когда мы начинаем назначать роли. У нас есть 5 ролей предложенных Ларманом, ну точнее Ларман их называет шаблонами. У нас есть создатель, контроллер, информационный эксперт, чистая выдумка, и посредник. Ролями я их назвал потому что они редко когда могут сочетаться, редко когда у нас может возникнуть ситуация где класс выполняет функцию чистой выдумки и выполняет роль информационный эксперт , потому , что это влечёт к снижению связности так как класс выполняет много дополнительных обязанностей. Мы распределяем роли изолированно друг от друга. Информационный эксперт — это вполне себе конкретная роль она напрямую связанна с данными. Информационными экспертами у нас являются такие классы, которые обладают необходимыми знаниями и возможностями по изменению этих знаний.
По сути это, если взять MVC, архитектурный паттерн, это модели, а модели у нас обладает познаниями о предметной области, содержат данные и обладают методами, которые изменяют эти данные. Методы, это есть ответственность класса которые мы распределяем. Информационный эксперты в MVC действительно чаще всего представлены моделями.
Контроллер. Контроллер тоже по своему функционалу совпадает по смыслу с MVC. Он принимает управляющее воздействие либо от системы, либо от графического интерфейса, и передает их информационному эксперту.
Создатель — это класс, который обладает достаточной компетенцией чтобы создать другие объекты, инициализировать их либо каким-то образом, с ними быть тесно связным. Создатель имеет легко узнаваемую конкретную роль, и обычно реализует паттерн абстрактная фабрика.
Роль посредника уменьшить зацепление разных классов друг на друга и выработать интерфейс. Посредник тоже узнаваем, он появляется на более поздних стадиях проектирования, когда мы начинаем нашу систему выводить на более гибкий уровень.
Чистая выдумка возникает в случаях, когда нам нужно либо реализовать задачи бизнес логики которые не ложатся не на одного эксперта информационного, либо какие-то специфические программа вещи. Многие из этих ролей действительно реализуется с помощью хорошо изученных паттернов.
Когда мы в таком ключе интерпретируем G.R.A.S.P мы можем его использовать практически. Если вы посмотрите, то во многих статьях приведены лишь описание, примеры, и совершенно не рассказано как связать их с паттернами, солидом и с другими архитектурными вещами. Я надеюсь моё пояснение окажется вам полезным.