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

    Почитать описание других паттернов.

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

    Известно девять GRAPS шаблонов, изначально описанных в книге Крейга Лармана «Применение UML и шаблонов проектирования». В отличие от привычных читателю паттернов из Банды Четырех, GRAPS паттерны не имеют выраженной структуры, четкой области применения и конкретной решаемой проблемы, а лишь представляют собой обобщенные подходы/рекомендации/принципы, используемые при проектировании дизайна системы.

    Рассмотрим характеристики основных GRASP шаблонов.

    Предметная область


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

    Судоходная компания «Навигатор+» является крупнейшим поставщиком услуг морских грузоперевозок. Головной офис компании состоит из трех отделов: отдел по работе с клиентами, отдел диспетчеризации рейсов, отдел комплектации рейсов. Менеджеры из отдела по работе с клиентами оформляют договора на доставку груза из пункта А в пункт В. Диспетчеры из отдела диспетчеризации рейсов отслеживают положение судов. Администраторы из отдела комплектации рейсов формируют грузовые рейсы на основании договоров с клиентами.

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


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

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


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

    Низкая связанность (Low Coupling) и Высокое зацепление (High Cohesion)


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

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

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

    Примером хорошего дизайна системы может служить набор утилит GNU Binutils для Linux. В котором, каждая утилита (если ее рассматривать как модуль) выполняет лишь минимальные обязанности (высокое зацепление) и почти ничего не знает о природе других утилит (низкая связность), в связи с чем может быть легко заменена на аналог в некотором варианте использования.

    Устойчивый к изменениям (Protected Variantions)


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

    Например, рассмотрим ситуацию расширения спректра услуг компании «Навигатор+». Будем считать, что судоходная компания начала заниматься пассажирскими перевозками. Для этого, реализуем точку устойчивости системы — перевозимую сущность (Entity).


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


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

    Известно понятие внешнего контроллера (Front Controller), который представляет всю систему в целом (агрегирует весь функционал системы в одном классе).

    Примером контроллера является класс Administrator, реализующий вариант использования системы администратором из отдела комплектации рейсов.


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

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


    Шаблон полиморфизм позволяет обрабатывать альтернативные варианты поведения на основе типа. При этом, альтернативные реализации приводятся к обобщенному интерфейсу.

    Рассмотрим интеграцию системы с внешними компонентами расчета тарифов на перевозку груза. Классы LocalTarificator и WorldWideTarificator являются адаптерами к соответствующим внешним компонентам.


    Применение шаблона полиморфизм позволяет в будущем легко модифицировать систему.

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


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

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


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

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


    Шаблон перенаправление реализует низкую связность между классами, путем назначения обязанностей по их взаимодействию дополнительному объекту — посреднику.

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

    Комментарии 22

      0
      может перенесете в тематический блог? думаю многим будет полезна эта информация.
        +1
        Обязательно перенесу, когда по количество плюсов посту станет ясно, что он действительно полезен :)
          0
          поправьте пожалуйста GRAPS на GRASP
        0
        Большое спасибо за информацию. Надо будет почитать книгу…
          –2
          скоро все прийдут опять к инкаплсуляции, наследовании и полиморфизму )))
          а вообщем хорошая информация. Спасибо!
            +4
            ru.wikipedia.org/wiki/GRASP

            Вы переформулировали эту статью и добавили рисунки и примеры, я прав? Я не говорю, что это плохо, я хочу чтобы все понимали, что собственно, вы показываете :).
              –2
              Не совсем, за основу была взята эта статья с википедии, указанная книга и вот эта статья.
                0
                Вот честно, статья на которую ссылаетесь — интересная. Дали бы на не топик-ссылку, все бы были счастливы.
              –3
              спасибо, кэп, за введение в ооп
                –1
                Pure Fabrication — это скорее антипаттерн, нежели наоборот.

                зы: шаблон полиморфизм — это круто.
                  +2
                  поставил комменту плюс. потом перечитал часть статьи про pure fabrication и понял что не прав.
                  Никакой это не антипаттерн. Конкретный пример использования — DaO (несколько натянутый пример, согласен).
                  +6
                  Паттерны Головного Мозга.

                  Ситуация когда субъект воспринимает рисунок из стрелочек и прямоугольничков, как дарованное с небес откровение о мироустройстве. И пользуясь напильником и топором пытается впихнуть любую ситуацию в рамки одной или нескольких таких картинок, забывая об особенностях предметной области и уже существующей кодовой базы. Плодит тонны вспомогательных классов (слався Адаптер!) и прочего гудрона. Речь бессвязная («бла-бла-бла стратегия бла-бла-бла итератор бла-бла-бла фабрика»).
                    +2
                    На хабре уже проскакивала статья по grasp habrahabr.ru/blogs/oop/38323/

                    Вы потеряли паттерн Creator, который неплохо сочетается с Information Expert…
                    Так же вы как-то вяло рассказали про Protected Variantions, в самой книге, Ларман рассказывает насколько это сложный принцип и как его сложно реализовать.
                      –2
                      Забавно — в комментах пишут критические замечания, но число плюсов растет. Видимо, зачарованный магическим словом, заклинанием «Паттерны!!! ААА!!», многие плюсуют не читая =))
                        +4
                        главная задача таких статей — чтобы человек обратил внимание на технологию и поковырял более детальные источники. и с этой задачей такие краткие статьи справляются очень даже хорошо. а чем раньше человек встретит информацию по GoF, GRAPS, SOLID — тем лучше. Поэтому мое мнение — такие статьи, пусть не глубокие, не самые точные, но без явных косяков и задающие вектор думок — очень полезны.
                      • НЛО прилетело и опубликовало эту надпись здесь
                          0
                          По-порядку.
                          В статье плохо раскрыты Низкая связанность (Low Coupling) и Высокое зацепление (High Cohesion)


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

                          чем контроллер отличается от «перенаправлятеля», это просто его частный случай?


                          Да, Вы правильно заметили, контроллер — это частный случай перенаправления. Дело в том, что у этих шалонов разные цели, поэтому они и называются по-разному.

                          Может ли в системе быть несколько экспертов?


                          Может :)
                          • НЛО прилетело и опубликовало эту надпись здесь
                              0
                              Это весьма общие слова которые мало дают представления о сущности этих мер/принципов. Я понимаю что «не существует универсальных рецептов счастья», все чего бы хотелось — не лазить на википедию за разъяснениями материала дающегося в статье.

                              Более того, даже на википедии Вы не найдете подобных разъяснений. Для этого, придется заглянуть в специализированную литературу — GoF, Мартина Флауэра, Крейга Лармана.

                              Эта статья рассчитана на людей которые знают все что изложено в статье?

                              Побойтесь бога. Статья рассчитана на людей, для которых ООП не просто сочетание букв, и даже не Объектно-ориентированное программирование. На людей, которые уже успели получить какой-либо опыт проектирования, изобрели несколько велосипедов и т.д.
                                0
                                Дык дайте тогда ответы, а не отговорки. И лучше — в том числе и прямо в статье.
                          0
                          Полезно, спасибо!
                            0
                            Есть подозрение, что контент является практически точной копией контента данного ресурса:
                            www.citforum.ru/SE/project/pattern/

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

                            Самое читаемое