ООП для ООП: GRASP

    GRASP — General Responsibility Assignment Software Patterns (основные шаблоны распределения обязанностей в программном обеспечении)

    Когда речь заходит о термине «ООП», все непременно подразумевают Объектно-Ориентированное Программирование, но сегодня речь пойдет не о нем. Почти. Сегодня я бы хотел рассказать о принципах Объектно-Ориентированного Проектирования, а в частности о шаблонах GRAPS и области их применения.

    GRASP состоит из 9 шаблонов:
    • Creator
    • Controller
    • Pure Fabrication
    • Information Expert
    • High Cohesion
    • Indirection
    • Low Coupling
    • Polymorphism
    • Protected Variations

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

    Чем больше опыта за плечами у разработчика ПО, тем больше он осознает смысл предварительного проектирования и макетирования, и тем позже он приступает к непосредственной разработке системы, даже если это БД из четырех таблиц. Это в нем отзывается лень :) Ведь именно из-за того, что в нескольких предыдущих проектах проектированию уделили слишком мало времени, в итоге система переписывалась на 40-60%%, а среднестатистический мыслящий программист не любит делать одно и то же по многу раз, вот и «приходится» уделять больше времени на предварительный анализ. И именно тут его начинают интересовать такие аспекты разработки ПО как объектно-ориентированный анализ и проектирование.

    Итак, поняв, что на моделирование необходимо уделить больше времени, актуальным становится следующий вопрос: «НУ а что ж такого тут проектировать, если и так все понятно?» Вобщем-то, если за плечами довольно большой груз знаний и опыта, а с ООА/П сталкиваться не приходилось, то все решения принимаются на уровне интуиции, а чтение литературы приводит только к систематизации знаний и, возможно, новым подходам. Так, со временем, для себя открывают GRASP.

    Как было сказано ранее, GRASP — это шаблоны проектирования. А именно — шаблоны, которые отвечают за взаимосвязь объектов в системе. Сколько раз вы задумывались над тем, где будет порождаться новый объект? В данном материале я хочу рассмотреть основные шаблоны GRAS ( «P» опускаю для избежания тавтологии, так как в аббревиатуре оно заменяется ловом «шаблоны»), на примере блога.

    Creator.


    Как часто вам приходилось задумываться о том, кто должен создавать объект X? Часто приходят к выводу, что объект должен создаваться независимо от кого-то, часто эту задачу возлагают на хранилище объектов (класс-коллекцию), а иногда на иные объекты системы. Что же правильно и какой вариант выбрать?
    Шаблон creator говорит нам какие условия должны соблюстись, что бы объекты верно порождали друг друга. Для этого есть несколько правил:
    объект А должен порождать объект Б, если:
    • объект А содержит или агрегирует объекты Б (содержит в себе как свойство или коллекцию)
    • объект А активно использует объекты Б (основной объем работы с объектом Б происходит посредством объекта А)
    • объект А обладает данными инициализации объекта Б (каждый раз при создании объекта Б, данные берутся из объекта А)




    Итак, взглянув на диаграмму отношений, на основании шаблона Creator можно сделать вывод, что экземпляры класса Post должны создаваться внутри класса Blog, а Comment — в Post. Почему так а не иначе? Например, почему Comment не должны создаваться в Blog? Ну хотя бы потому, что именно Post содержит в себе экземпляры Comment, а так же Post обладает информацией для создания экземпляра Comment (в нашем случае это всего лишь указатель на родителя, но даже этим не обладает Blog по отношению к Comment).

    Information Expert


    Информационный эксперт, как следует из названия, занимается не чем иным, как предоставлением информации об объекте. В нашем случае Information Expert должен отвечать на такие вопросы:
    • Кто должен знать кол-во комментариев к посту?
    • Кто должен знать общее кол-во комментариев в блоге?

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



    Но при этом именно Post должен отвечать за такие аспекты, как «получить название поста» ( getTitle() ), «получить пост», «получить автора» и пр.

    Controller


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

    Low Coupling


    Низкая связанность, отвечает за то, что бы объекты в системе знали друг о друге как можно меньше. Ведь чем меньше объект знает о других объектах, тем больше будет изолировано и тем меньше правок необходимо будет делать, если в системе что-то поменяется.
    На наших диаграммах все хорошо. Blog ничего не знает о Comment, а степени связанности у каждого класса составляют всего лишь единицу. В более сложных системах связей бывает гораздо больше, и шаблон Low Coupling позволяет избежать следующих проблем:
    • При изменении в связанных классах, необходимо делать локальные изменения в данном классе
    • Понимание каждого класса в отдельности усложняется и требует изучения всех связанных классов
    • Повторное использование становится невозможным из-за того, что перетянув часть системы, необходимо тянуть почти всю систему.


    High Cohesion


    Высокая степень зацепления — так переводится название шаблона. Это противовес предыдущего шаблона. Зацепление — процесс взаимодействия класса с другими классами системы и область ответственности за действия. Рассмотрим две диаграммы:





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

    Все. На первое время достаточно :) Если статья будет иметь успех — обещаю рассказать о некоторых других шаблонах GRASP, а так же о шаблонах GoF и многом другом из мира ООА/ООП.

    оригинал статьи в моем блоге
    Share post

    Comments 42

      +1
      Очень актуальная для меня тема, сейчас «вынашиваю» в голове сложную систему объектов, и GRASP как раз то, что нужно, чтоб выйти за пределы своей интуиции.
      Было бы интересно почитать, если Вы продолжите развивать тематику в последующих статья. В любом случае спасибо, теперь знаю в какую сторону «рыть» и как называется то, что мне надо.
        +1
        «вынашивать» в голове сложные системы очень сложно. Рекомендую делать заметки в виде UML — позволяет более отчетливо понимать проблему и связь в конечной системе, да и как артефакт документации UML диаграммы подойдут как нельзя лучше.

        З.Ы. Сразу хочу заметить что я не говорю везде и всегда использовать UML. Он необходим только в достаточных объемах в тех местах, где возможно разногласия с точки зрения архитектуры. Более того, применять спец. софт вовсе не обязательно (я использую Umbrello), бумаги и карандаша часто хватает заглаза, а в крайнем случае фотоаппараты никто не отменял :)
          0
          Лучше все таки бумага и карандаш, особенно на стадии вынашивания. На изучение UML придется только портратить время, хотя не спорю, оно может и окупится в дальнейшем.

          Но для меня нет ничего лучше большого чистого листа бумаги и карандаша, чтобы излить свои мысли и освободить голову :)
            +1
            Можно еще mindmap попробовать, очень помогает, именно продумывать архитектуру.
            А UML это если совсем формализовать продуманное и до мелочей опускаться.
              0
              Минут 30 максимум, ибо реально надо там только вариант испльзования, в котором объект с сообщением, а далее класс и связь.

              Все.
          0
          Имхо, про шаблоны уже очень много рассказано. Есть отличные книги и статьи про это, например тут много ссылок на них:

          GRASP_(Object_Oriented_Design)

          Design_pattern_(computer_science)

          Design_Patterns

          Если кто-то еще не читал Макконнелла или банду четырех — они просто обязаны прочитать эти книги. Сейчас в IT иногда даже разговаривать сложно с человеком, который паттернов не знает.

          Но все равно ваши статьи могут быть полезны для людей, если заставят их прочитать эти книги, т.к. по-любому толстая книга дает больше информации, чем обзорная статья.
          Поэтому было бы большим плюсом, если бы вы добавили ссылки на книги в конце поста.
            0
            Написать-то написано, но к примеру по GRASP — к каждому определению одно-два предложения + для многих есть проблема читать на англ. А на рус. материалов еще меньше, а по GoF вообще нет в вики перевода
              0
              Я не про вики. Большинство книг по шаблонам уже переведено на русский. Можно ссылки не на amazon давать, а на ozon, например.

              В вики тоже просто обзорные статьи, в которых не так много информации, как в книгах.
              Однако некоторые, например, Design_pattern_(computer_science) — просто отличные.

              То есть еще раз повторюсь, что я только за такие обзорные статьи, но они не должны заменять книги, а подталкивать людей к чтению книг. А значит и ссылки на книги обязательны.
                0
                Да я и сам за книги :)
                /me нежно смотрит на полку, заставленную увесистой литературой по предметным областям
                  +1
                  Я выбрал «правильные» книги?

                  Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес. Приемы объектно-ориентированного проектирования. Паттерны проектирования
                  www.ozon.ru/context/detail/id/2457392/

                  Крэг Ларман. Применение UML 2.0 и шаблонов проектирования. Введение в объектно-ориентированный анализ, проектирование и итеративную разработку
                  www.ozon.ru/context/detail/id/3105480/

                  Что-то ещё можно добавить?
                  Спасибо.
                    0
                    По паттернам это классические книги. Есть еще много дополнительных, но они только добавляют несколько новых паттернов.
                      +1
                      можно еще добавить Мартина Фаулера: рефакторинг и архитектуру корпоративных приложений. я бы даже сначала прочитал рефакторинг фаулера, потом лармана, а потом гамму, хелма и др.
                        +2
                        Фаулер классный мужик. Была возможность пообщаться. Но и он не смог устоять от того, что бы не переобозвать известный GoF шаблон по своему. Ну пиар блин… :-)
                0
                а книги можете порекомендовать по этой теме?
                  0
                  пока писал пост уже ответили ;)
                    0
                    Крег Ларман «Применение UML2.0 и шаблоны проектирования», но сразу предупреждаю — книга очень тяжело поддается восприятию и подготовка читателя должна быть выше средней…
                      +2
                      Кстати, к нам Ларман приезжал на работу пару месяцев назад — интересный и умный человек. Но у него, имхо, про Agile гораздо приятнее книги, чем по шаблонам.
                      А по шаблонам — банда четырех лучшая. Или вот онлайн на русском мне нравится: citforum.ru/SE/project/pattern/
                        +1
                        А еще Ларман настолько могуч, что умудрился убедить наше руководство начать внедрение feature teams. Я про это немного в своем посте писал.

                        А про UML он отзывался не очень хорошо на своей презентации. Ему теперь больше нравится на белой доске или на бумажках простыми символами рисовать и это правильно.
                    +1
                    Тема этой статьи очень подробно раскрывается в книге Крэга Лармана «Применение UML 2.0 и шаблонов проектирования. Введение в объектно-ориентированный анализ, проектирование и итеративную разработку».
                    Видимо автор оттуда идеи черпал (некоторые фразы и речевые обороты очень знакомы).
                    Советую почитать.
                      0
                      автор писал из головы, хотя скрывать не станет — недели две как закончил бороться с этой книгой :)
                        0
                        :). А я как раз сейчас последнюю главу дочитываю — очень занимательная книга. После прочтения каждой новой главы появляется стойкое желание заняться рефакторингом старых проектов ).
                      0
                      Многое из этого я уже знал, использовал интуитивно, но теперь знаю научные названия. За это спасибо! Ждем продолжения цикла.
                        +4
                        Видимо я сильно рискну и категорически выбьюсь из дружного хора поклонников Крега Лармана, но таки скажу – крайне неудачная книга.

                        Шаблоны проектирования давно стали стандартом для квалифицированного разработчика. По своей сути, шаблон это некий образец того, как должны между собой соотноситься (быть организованы) объекты/классы для того что бы максимально удобно и безопасно решить ту или иную задачу. В своё время, Бригада (“банда”) Четырёх (GoF) подвела отличную мощную черту тщательным образом задокументировав самые ходовые приёмы организации объектов и, дав им те названия, которые эмпирически сложились лет за 10. На основании этой книги вы можете сказать, что вот тут у вас Синглетон, тут Фабрика, а тут Мост. И квалифицированный разработчик вас поймёт.

                        Что сделал Ларман? Для начала он перепутал шаблоны с принципами. А затем – дал известным вещам собственные названия, тем самым кардинально запутав людей. Особенно тех, кто не читал GoF, и начал изучение шаблонов по Ларману. Низкая связанность – это не шаблон, это принцип проектирования. А шаблон, это пример организации объектов, что бы этой низкой связанности достичь. Если приводить пример из жизни, то, упрощённо говоря, можно постулировать принцип – угловое соединение деревянных досок в кухонных столах должно быть прочным. А можно привести шаблон – как и куда правильно вкрутить болты, что бы угловое соединение досок было действительно прочным. Семантически это несколько разные вещи: образец использования предмета и некий принцип, которому нужно следовать.

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

                        В итоге мы и имеем некую забавную ситуацию, когда название шаблона выглядит как название принципа и при этом противоречит другому названию. Низкая связанность, высокое зацепление… И это всё при том, что в канонической книге Гофа всё это постулировано очень точно и правильно. Хотите иметь хорошую развязку — применяёте такой-то шаблон и будет вам счастьё и вот почему… Хотите иметь сильную связь, которая нужна в таких и таких-то случаях, берите вот такой для этого и такой для этого. Никаких противоречий и туманных описаний.

                        Учитывая, что ГоФ книга серьёзная, точная и популизмом не балуется, со своей стороны порекомендую крайне замечательно написанную книгу — Head First Design Patterns:

                        oreilly.com/catalog/9780596007126/

                        Книга написана очень доступно, увлекательно и с хорошим юмором, использует правильную терминологию и содержит много удачных визуальных примеров из окружающей бытовой действительности, которые отражают суть того или иного паттерна. К сожалению, на русский язык книга вроде как не переводилась.
                          0
                          Вы явно что-то путаете :) Из того, что написано в топике, Ларман не имеет ни к чему никакого отношения :) GRASP не его «придумка».
                          В остальном Вы в чем-то правы, а в чем-то нет — не думаю что стоит начинать холивары
                            +2
                            Это Ларман путает. И переводчики путают. GRASP это не набор шаблонов, это набор рекомендаций и принципов которыми желательно руководствоваться при принятии того или иного проектного решения, которые кто-то сдуру обозвал шаблонами. Они рекомендуют из чего исходить и что принимать во внимание, что бы ничего не упустить. В этом и есть ошибка Лармана. Он обозвал рекомендации шаблонами и на этом построил книгу. Эту книгу тщательно перевели на русский (и продолжают переводить новые издания). Как итог, неудачный учебник с перепутанной терминологией, который является стартовым для молодых разработчиков. Ну и следствие — люди не знают что такое Фабрика, но пространно рассуждают о низком связывании и Криейторах по Ларману.

                            ПС: Это удобно при собеседовании на работу. Сразу видно, что чел не читал Гофа, но прочёл куски Лармана. Смысла не понимают. Умные слова — знают. :-)
                              0
                              «GRASP это не набор шаблонов»

                              возьметесь расшифровать аббревиатуру? это во-первых

                              во-вторых — при чем тут Ларман? :) Не он назвал шаблонами — не он! это же не его термин…

                              в-третьих — речь шла абсолютно не об «учебнике»

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

                              в-пятых — ну я же просил без холиваров :)
                                0
                                … не надо мешать шаблоны проектирования, структурные шаблоны, поведенческие шаблоны и пр…
                                — Именно что и надо мешать. Ибо структурные шаблоны и поведенческие шаблоны являются частью шаблонов проектирования. Не надо мешать шаблоны и принципы.
                                  +1
                                  И да. Возьмусь расшифровать аббревиатуру:

                                  «GRASP stands for General Responsibility Assignment Software Patterns (or sometimes Principles).»

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

                                  en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)

                                  Как видите, там везде фигурирует слово Principles. И речь идёт не о Design Patterns, а об общих подходах к проектированию, что англоговорящие также обзывают словом паттернс, но Softaware patterns. То есть подходы и правила. Но не образцы! Не нужно их мешать в кучу.

                                    +1
                                    PS: Что особенно грустно, так это то, что люди не очень то и обсуждают столь фундаментальные вещи, от которых тотально зависит успех практически любого проекта. И не важно, образцы это или подходы. Важно то, что эти вещи важны, но их важности мало кто понимает. :-)
                                      0
                                      во-первых, если бы Вы внимательнее читали ЧТО я написал в статье, то не пропустили бы следующий абзац: «При этом хочу добавить что не все шаблоны являются «программными». Некоторые из них (например High Cohesion и Low Coupling) это принципы»

                                      во-вторых — все-равно не понимаю при чем тут Ларман к моему топику? :)
                                    0
                                    PS: Книга Лармана называется «Applying UML and Paterns». Перевели это как «Применение UML и шаблонов проектирования». Что и есть радикально неправильно. Шаблоны Проектирования это давно устоявшийся термин (Design Patterns), и это технический термин, связанный с набором приёмов организации кода, а не общих принципов ООП. К сожалению, в силу невысокой квалификации переводчиков, получился заментый смаз, когда одно смешалось с другим и возникла путаница. На месте Лармана я бы не использовал термин Patterns.
                                      +1
                                      принципы, шаблоны, патерны… Какая разница как называть, определения мало что меняют. Я читал гамму, хелма и сотоваришей, а до этого фаулеровские архитектурные патерны — важно не столько кто и как называет, а то, какой смысл вкладывается в то или иное понятие. Можно наизусть выучить все шаблоны ГоФ, но при этом абсолютно не уметь их применять на практике и по назначению. Книга Лармана, на мой взгляд, хороша тем, что показывает применимость шаблонов на конкретных, приближенных к реальности примерах. Показывает как можно грамотно комбинировать проектные решения чтобы они удовлетворяли основным принципам ооп/а и при этом вписывались в рамки известных шаблонов.
                                      Короче как и в любом другом деле, к чтению книг по ооп нужно подходить с умом. Это не тот случай, где просто тупое копирование и бездумное следование всему, что написано приводит к положительным результатам.

                                        +2
                                        Разница в том, что есть образцы, а есть принципы и подходы. Если человек обзывает подходы образцами, то он путает других людей и формирует у них чувство. что это и есть те самые образцы, которые в действительности есть подходы. :-)

                                        Как итог — человек не видит разницы и полагает, что он знает то, что в действительности — не знает. Такая вот беда.

                                        Для человека который понимает всё, это конечно же без разницы. Он и сам в состоянии расставить акценты и использовать термины правильно.
                                  0
                                  Молодец, правильное замечание. Но не настолько, чтобы называть книгу крайне неудачной. В конце концов время расставит все на свои места и человек начинает понимать, что эти т.н. «патерны» несколько низкоуровневые и не совсем похожи на те, что в GoF. Кстати, кое-что из GoF там тоже имеется. Кроме того Ларман описывает не только эти т.н. принципы но и дает примеры анализа и проектирования соответственно и в очень неплохой форме. Вцелом из нее можно много чего почерпнуть.
                                  А Head-First это вообще нечто. Практически вся серия это ацкий отжег. К сожалению Design Patterns вот расписаны не в полном составе, но те, что есть, просто на 5 баллов.
                                  0
                                  Отлично! Просто и со знанием дела.
                                  Небольшой, как мне кажется, недостаток — в описании Creator:

                                  Шаблон creator говорит нам какие условия должны соблюстись, что бы объекты верно порождали друг друга. Для этого есть несколько правил:
                                  ...


                                  … можно сделать вывод, что экземпляры класса Post должны создаваться внутри класса Blog, а Comment — в Post. Почему так а не иначе? Например, почему Comment не должны создаваться в Blog? Ну хотя бы потому, что именно Post содержит в себе экземпляры Comment, а так же Post обладает информацией для создания экземпляра Comment...


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

                                    Излишество в интерфейсе, в общем, на сколько я понял. =)
                                    +1
                                    ОЧЕНЬ понравилось! Я прям в восторге, спасибо. ) Продолжайте, очень актуально. ) Как раз нахожусь сейчас где-то в районе той стадии, когда неприемлемо сразу кодировать, потому что жалко тратить свои силы на исправление ошибок потом )
                                      +1
                                      Банду четырёх я тоже читал, но мне больше запомнилась другая книжка. Она более приближена к реалиям построения вэб-приложения. В ней обсуждаются такие интересные для вэб-разработчика вопросы как загрузка/сохранение объектов из/в базу данных, MVC (не в том виде, как это обсасывается на хабре «Посмотрите, дети!.. Какое чудо!»), расслоение системы.

                                      Мартин Фаулер «Архитектура корпоративных программных приложений»
                                      • UFO just landed and posted this here
                                        0
                                        Бесподобно! Продолжайте! Именно то, что сейчас нужно!
                                          0
                                          Когда то эта статья мне очень помогла :) надеюсь и здесь пригодится
                                          www.citforum.ru/SE/project/pattern/
                                            0
                                            Согласно книжке «Технологии разработки программного обеспечения» (С.А.Орлов) термины «coupling» и «cohesion» переводятся ровно наоборот, а именно:

                                            cohesion — связность
                                            coupling — сцепление

                                            Only users with full accounts can post comments. Log in, please.