Комментарии 42
Очень актуальная для меня тема, сейчас «вынашиваю» в голове сложную систему объектов, и GRASP как раз то, что нужно, чтоб выйти за пределы своей интуиции.
Было бы интересно почитать, если Вы продолжите развивать тематику в последующих статья. В любом случае спасибо, теперь знаю в какую сторону «рыть» и как называется то, что мне надо.
Было бы интересно почитать, если Вы продолжите развивать тематику в последующих статья. В любом случае спасибо, теперь знаю в какую сторону «рыть» и как называется то, что мне надо.
«вынашивать» в голове сложные системы очень сложно. Рекомендую делать заметки в виде UML — позволяет более отчетливо понимать проблему и связь в конечной системе, да и как артефакт документации UML диаграммы подойдут как нельзя лучше.
З.Ы. Сразу хочу заметить что я не говорю везде и всегда использовать UML. Он необходим только в достаточных объемах в тех местах, где возможно разногласия с точки зрения архитектуры. Более того, применять спец. софт вовсе не обязательно (я использую Umbrello), бумаги и карандаша часто хватает заглаза, а в крайнем случае фотоаппараты никто не отменял :)
З.Ы. Сразу хочу заметить что я не говорю везде и всегда использовать UML. Он необходим только в достаточных объемах в тех местах, где возможно разногласия с точки зрения архитектуры. Более того, применять спец. софт вовсе не обязательно (я использую Umbrello), бумаги и карандаша часто хватает заглаза, а в крайнем случае фотоаппараты никто не отменял :)
Имхо, про шаблоны уже очень много рассказано. Есть отличные книги и статьи про это, например тут много ссылок на них:
GRASP_(Object_Oriented_Design)
Design_pattern_(computer_science)
Design_Patterns
Если кто-то еще не читал Макконнелла или банду четырех — они просто обязаны прочитать эти книги. Сейчас в IT иногда даже разговаривать сложно с человеком, который паттернов не знает.
Но все равно ваши статьи могут быть полезны для людей, если заставят их прочитать эти книги, т.к. по-любому толстая книга дает больше информации, чем обзорная статья.
Поэтому было бы большим плюсом, если бы вы добавили ссылки на книги в конце поста.
GRASP_(Object_Oriented_Design)
Design_pattern_(computer_science)
Design_Patterns
Если кто-то еще не читал Макконнелла или банду четырех — они просто обязаны прочитать эти книги. Сейчас в IT иногда даже разговаривать сложно с человеком, который паттернов не знает.
Но все равно ваши статьи могут быть полезны для людей, если заставят их прочитать эти книги, т.к. по-любому толстая книга дает больше информации, чем обзорная статья.
Поэтому было бы большим плюсом, если бы вы добавили ссылки на книги в конце поста.
Написать-то написано, но к примеру по GRASP — к каждому определению одно-два предложения + для многих есть проблема читать на англ. А на рус. материалов еще меньше, а по GoF вообще нет в вики перевода
Я не про вики. Большинство книг по шаблонам уже переведено на русский. Можно ссылки не на amazon давать, а на ozon, например.
В вики тоже просто обзорные статьи, в которых не так много информации, как в книгах.
Однако некоторые, например, Design_pattern_(computer_science) — просто отличные.
То есть еще раз повторюсь, что я только за такие обзорные статьи, но они не должны заменять книги, а подталкивать людей к чтению книг. А значит и ссылки на книги обязательны.
В вики тоже просто обзорные статьи, в которых не так много информации, как в книгах.
Однако некоторые, например, Design_pattern_(computer_science) — просто отличные.
То есть еще раз повторюсь, что я только за такие обзорные статьи, но они не должны заменять книги, а подталкивать людей к чтению книг. А значит и ссылки на книги обязательны.
Да я и сам за книги :)
/me нежно смотрит на полку, заставленную увесистой литературой по предметным областям
/me нежно смотрит на полку, заставленную увесистой литературой по предметным областям
Я выбрал «правильные» книги?
Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес. Приемы объектно-ориентированного проектирования. Паттерны проектирования
www.ozon.ru/context/detail/id/2457392/
Крэг Ларман. Применение UML 2.0 и шаблонов проектирования. Введение в объектно-ориентированный анализ, проектирование и итеративную разработку
www.ozon.ru/context/detail/id/3105480/
Что-то ещё можно добавить?
Спасибо.
Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес. Приемы объектно-ориентированного проектирования. Паттерны проектирования
www.ozon.ru/context/detail/id/2457392/
Крэг Ларман. Применение UML 2.0 и шаблонов проектирования. Введение в объектно-ориентированный анализ, проектирование и итеративную разработку
www.ozon.ru/context/detail/id/3105480/
Что-то ещё можно добавить?
Спасибо.
По паттернам это классические книги. Есть еще много дополнительных, но они только добавляют несколько новых паттернов.
можно еще добавить Мартина Фаулера: рефакторинг и архитектуру корпоративных приложений. я бы даже сначала прочитал рефакторинг фаулера, потом лармана, а потом гамму, хелма и др.
а книги можете порекомендовать по этой теме?
пока писал пост уже ответили ;)
Крег Ларман «Применение UML2.0 и шаблоны проектирования», но сразу предупреждаю — книга очень тяжело поддается восприятию и подготовка читателя должна быть выше средней…
Кстати, к нам Ларман приезжал на работу пару месяцев назад — интересный и умный человек. Но у него, имхо, про Agile гораздо приятнее книги, чем по шаблонам.
А по шаблонам — банда четырех лучшая. Или вот онлайн на русском мне нравится: citforum.ru/SE/project/pattern/
А по шаблонам — банда четырех лучшая. Или вот онлайн на русском мне нравится: citforum.ru/SE/project/pattern/
А еще Ларман настолько могуч, что умудрился убедить наше руководство начать внедрение feature teams. Я про это немного в своем посте писал.
А про UML он отзывался не очень хорошо на своей презентации. Ему теперь больше нравится на белой доске или на бумажках простыми символами рисовать и это правильно.
А про UML он отзывался не очень хорошо на своей презентации. Ему теперь больше нравится на белой доске или на бумажках простыми символами рисовать и это правильно.
Тема этой статьи очень подробно раскрывается в книге Крэга Лармана «Применение UML 2.0 и шаблонов проектирования. Введение в объектно-ориентированный анализ, проектирование и итеративную разработку».
Видимо автор оттуда идеи черпал (некоторые фразы и речевые обороты очень знакомы).
Советую почитать.
Видимо автор оттуда идеи черпал (некоторые фразы и речевые обороты очень знакомы).
Советую почитать.
Многое из этого я уже знал, использовал интуитивно, но теперь знаю научные названия. За это спасибо! Ждем продолжения цикла.
Видимо я сильно рискну и категорически выбьюсь из дружного хора поклонников Крега Лармана, но таки скажу – крайне неудачная книга.
Шаблоны проектирования давно стали стандартом для квалифицированного разработчика. По своей сути, шаблон это некий образец того, как должны между собой соотноситься (быть организованы) объекты/классы для того что бы максимально удобно и безопасно решить ту или иную задачу. В своё время, Бригада (“банда”) Четырёх (GoF) подвела отличную мощную черту тщательным образом задокументировав самые ходовые приёмы организации объектов и, дав им те названия, которые эмпирически сложились лет за 10. На основании этой книги вы можете сказать, что вот тут у вас Синглетон, тут Фабрика, а тут Мост. И квалифицированный разработчик вас поймёт.
Что сделал Ларман? Для начала он перепутал шаблоны с принципами. А затем – дал известным вещам собственные названия, тем самым кардинально запутав людей. Особенно тех, кто не читал GoF, и начал изучение шаблонов по Ларману. Низкая связанность – это не шаблон, это принцип проектирования. А шаблон, это пример организации объектов, что бы этой низкой связанности достичь. Если приводить пример из жизни, то, упрощённо говоря, можно постулировать принцип – угловое соединение деревянных досок в кухонных столах должно быть прочным. А можно привести шаблон – как и куда правильно вкрутить болты, что бы угловое соединение досок было действительно прочным. Семантически это несколько разные вещи: образец использования предмета и некий принцип, которому нужно следовать.
Вот Ларман это постоянно путает, обзывает многие вещи по своему, да и вообще часто постулирует неправильные принципы. Оттого книга и читается крайне тяжело, поскольку очень сложно понять, что же хотел сказать автор, ибо это выглядит или очень общё или непонятно. Явных глупостей он там не говорит, в целом всё вроде верно, но запутал он всех своими новыми терминами довольно таки основательно.
В итоге мы и имеем некую забавную ситуацию, когда название шаблона выглядит как название принципа и при этом противоречит другому названию. Низкая связанность, высокое зацепление… И это всё при том, что в канонической книге Гофа всё это постулировано очень точно и правильно. Хотите иметь хорошую развязку — применяёте такой-то шаблон и будет вам счастьё и вот почему… Хотите иметь сильную связь, которая нужна в таких и таких-то случаях, берите вот такой для этого и такой для этого. Никаких противоречий и туманных описаний.
Учитывая, что ГоФ книга серьёзная, точная и популизмом не балуется, со своей стороны порекомендую крайне замечательно написанную книгу — Head First Design Patterns:
oreilly.com/catalog/9780596007126/
Книга написана очень доступно, увлекательно и с хорошим юмором, использует правильную терминологию и содержит много удачных визуальных примеров из окружающей бытовой действительности, которые отражают суть того или иного паттерна. К сожалению, на русский язык книга вроде как не переводилась.
Шаблоны проектирования давно стали стандартом для квалифицированного разработчика. По своей сути, шаблон это некий образец того, как должны между собой соотноситься (быть организованы) объекты/классы для того что бы максимально удобно и безопасно решить ту или иную задачу. В своё время, Бригада (“банда”) Четырёх (GoF) подвела отличную мощную черту тщательным образом задокументировав самые ходовые приёмы организации объектов и, дав им те названия, которые эмпирически сложились лет за 10. На основании этой книги вы можете сказать, что вот тут у вас Синглетон, тут Фабрика, а тут Мост. И квалифицированный разработчик вас поймёт.
Что сделал Ларман? Для начала он перепутал шаблоны с принципами. А затем – дал известным вещам собственные названия, тем самым кардинально запутав людей. Особенно тех, кто не читал GoF, и начал изучение шаблонов по Ларману. Низкая связанность – это не шаблон, это принцип проектирования. А шаблон, это пример организации объектов, что бы этой низкой связанности достичь. Если приводить пример из жизни, то, упрощённо говоря, можно постулировать принцип – угловое соединение деревянных досок в кухонных столах должно быть прочным. А можно привести шаблон – как и куда правильно вкрутить болты, что бы угловое соединение досок было действительно прочным. Семантически это несколько разные вещи: образец использования предмета и некий принцип, которому нужно следовать.
Вот Ларман это постоянно путает, обзывает многие вещи по своему, да и вообще часто постулирует неправильные принципы. Оттого книга и читается крайне тяжело, поскольку очень сложно понять, что же хотел сказать автор, ибо это выглядит или очень общё или непонятно. Явных глупостей он там не говорит, в целом всё вроде верно, но запутал он всех своими новыми терминами довольно таки основательно.
В итоге мы и имеем некую забавную ситуацию, когда название шаблона выглядит как название принципа и при этом противоречит другому названию. Низкая связанность, высокое зацепление… И это всё при том, что в канонической книге Гофа всё это постулировано очень точно и правильно. Хотите иметь хорошую развязку — применяёте такой-то шаблон и будет вам счастьё и вот почему… Хотите иметь сильную связь, которая нужна в таких и таких-то случаях, берите вот такой для этого и такой для этого. Никаких противоречий и туманных описаний.
Учитывая, что ГоФ книга серьёзная, точная и популизмом не балуется, со своей стороны порекомендую крайне замечательно написанную книгу — Head First Design Patterns:
oreilly.com/catalog/9780596007126/
Книга написана очень доступно, увлекательно и с хорошим юмором, использует правильную терминологию и содержит много удачных визуальных примеров из окружающей бытовой действительности, которые отражают суть того или иного паттерна. К сожалению, на русский язык книга вроде как не переводилась.
Вы явно что-то путаете :) Из того, что написано в топике, Ларман не имеет ни к чему никакого отношения :) GRASP не его «придумка».
В остальном Вы в чем-то правы, а в чем-то нет — не думаю что стоит начинать холивары
В остальном Вы в чем-то правы, а в чем-то нет — не думаю что стоит начинать холивары
Это Ларман путает. И переводчики путают. GRASP это не набор шаблонов, это набор рекомендаций и принципов которыми желательно руководствоваться при принятии того или иного проектного решения, которые кто-то сдуру обозвал шаблонами. Они рекомендуют из чего исходить и что принимать во внимание, что бы ничего не упустить. В этом и есть ошибка Лармана. Он обозвал рекомендации шаблонами и на этом построил книгу. Эту книгу тщательно перевели на русский (и продолжают переводить новые издания). Как итог, неудачный учебник с перепутанной терминологией, который является стартовым для молодых разработчиков. Ну и следствие — люди не знают что такое Фабрика, но пространно рассуждают о низком связывании и Криейторах по Ларману.
ПС: Это удобно при собеседовании на работу. Сразу видно, что чел не читал Гофа, но прочёл куски Лармана. Смысла не понимают. Умные слова — знают. :-)
ПС: Это удобно при собеседовании на работу. Сразу видно, что чел не читал Гофа, но прочёл куски Лармана. Смысла не понимают. Умные слова — знают. :-)
«GRASP это не набор шаблонов»
возьметесь расшифровать аббревиатуру? это во-первых
во-вторых — при чем тут Ларман? :) Не он назвал шаблонами — не он! это же не его термин…
в-третьих — речь шла абсолютно не об «учебнике»
в-четвертых — не надо мешать шаблоны проектирования, структурные шаблоны, поведенческие шаблоны и пр. Вы явно чего-то недопонимаете
в-пятых — ну я же просил без холиваров :)
возьметесь расшифровать аббревиатуру? это во-первых
во-вторых — при чем тут Ларман? :) Не он назвал шаблонами — не он! это же не его термин…
в-третьих — речь шла абсолютно не об «учебнике»
в-четвертых — не надо мешать шаблоны проектирования, структурные шаблоны, поведенческие шаблоны и пр. Вы явно чего-то недопонимаете
в-пятых — ну я же просил без холиваров :)
… не надо мешать шаблоны проектирования, структурные шаблоны, поведенческие шаблоны и пр…
— Именно что и надо мешать. Ибо структурные шаблоны и поведенческие шаблоны являются частью шаблонов проектирования. Не надо мешать шаблоны и принципы.
— Именно что и надо мешать. Ибо структурные шаблоны и поведенческие шаблоны являются частью шаблонов проектирования. Не надо мешать шаблоны и принципы.
И да. Возьмусь расшифровать аббревиатуру:
«GRASP stands for General Responsibility Assignment Software Patterns (or sometimes Principles).»
Дабы не ошибиться, и не брать всё на свой авторитет, который безразличен Хабра людям, взял прямо из англоязычной вики.
en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)
Как видите, там везде фигурирует слово Principles. И речь идёт не о Design Patterns, а об общих подходах к проектированию, что англоговорящие также обзывают словом паттернс, но Softaware patterns. То есть подходы и правила. Но не образцы! Не нужно их мешать в кучу.
«GRASP stands for General Responsibility Assignment Software Patterns (or sometimes Principles).»
Дабы не ошибиться, и не брать всё на свой авторитет, который безразличен Хабра людям, взял прямо из англоязычной вики.
en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design)
Как видите, там везде фигурирует слово Principles. И речь идёт не о Design Patterns, а об общих подходах к проектированию, что англоговорящие также обзывают словом паттернс, но Softaware patterns. То есть подходы и правила. Но не образцы! Не нужно их мешать в кучу.
PS: Что особенно грустно, так это то, что люди не очень то и обсуждают столь фундаментальные вещи, от которых тотально зависит успех практически любого проекта. И не важно, образцы это или подходы. Важно то, что эти вещи важны, но их важности мало кто понимает. :-)
во-первых, если бы Вы внимательнее читали ЧТО я написал в статье, то не пропустили бы следующий абзац: «При этом хочу добавить что не все шаблоны являются «программными». Некоторые из них (например High Cohesion и Low Coupling) это принципы»
во-вторых — все-равно не понимаю при чем тут Ларман к моему топику? :)
во-вторых — все-равно не понимаю при чем тут Ларман к моему топику? :)
PS: Книга Лармана называется «Applying UML and Paterns». Перевели это как «Применение UML и шаблонов проектирования». Что и есть радикально неправильно. Шаблоны Проектирования это давно устоявшийся термин (Design Patterns), и это технический термин, связанный с набором приёмов организации кода, а не общих принципов ООП. К сожалению, в силу невысокой квалификации переводчиков, получился заментый смаз, когда одно смешалось с другим и возникла путаница. На месте Лармана я бы не использовал термин Patterns.
принципы, шаблоны, патерны… Какая разница как называть, определения мало что меняют. Я читал гамму, хелма и сотоваришей, а до этого фаулеровские архитектурные патерны — важно не столько кто и как называет, а то, какой смысл вкладывается в то или иное понятие. Можно наизусть выучить все шаблоны ГоФ, но при этом абсолютно не уметь их применять на практике и по назначению. Книга Лармана, на мой взгляд, хороша тем, что показывает применимость шаблонов на конкретных, приближенных к реальности примерах. Показывает как можно грамотно комбинировать проектные решения чтобы они удовлетворяли основным принципам ооп/а и при этом вписывались в рамки известных шаблонов.
Короче как и в любом другом деле, к чтению книг по ооп нужно подходить с умом. Это не тот случай, где просто тупое копирование и бездумное следование всему, что написано приводит к положительным результатам.
Короче как и в любом другом деле, к чтению книг по ооп нужно подходить с умом. Это не тот случай, где просто тупое копирование и бездумное следование всему, что написано приводит к положительным результатам.
Разница в том, что есть образцы, а есть принципы и подходы. Если человек обзывает подходы образцами, то он путает других людей и формирует у них чувство. что это и есть те самые образцы, которые в действительности есть подходы. :-)
Как итог — человек не видит разницы и полагает, что он знает то, что в действительности — не знает. Такая вот беда.
Для человека который понимает всё, это конечно же без разницы. Он и сам в состоянии расставить акценты и использовать термины правильно.
Как итог — человек не видит разницы и полагает, что он знает то, что в действительности — не знает. Такая вот беда.
Для человека который понимает всё, это конечно же без разницы. Он и сам в состоянии расставить акценты и использовать термины правильно.
Молодец, правильное замечание. Но не настолько, чтобы называть книгу крайне неудачной. В конце концов время расставит все на свои места и человек начинает понимать, что эти т.н. «патерны» несколько низкоуровневые и не совсем похожи на те, что в GoF. Кстати, кое-что из GoF там тоже имеется. Кроме того Ларман описывает не только эти т.н. принципы но и дает примеры анализа и проектирования соответственно и в очень неплохой форме. Вцелом из нее можно много чего почерпнуть.
А Head-First это вообще нечто. Практически вся серия это ацкий отжег. К сожалению Design Patterns вот расписаны не в полном составе, но те, что есть, просто на 5 баллов.
А Head-First это вообще нечто. Практически вся серия это ацкий отжег. К сожалению Design Patterns вот расписаны не в полном составе, но те, что есть, просто на 5 баллов.
Отлично! Просто и со знанием дела.
Небольшой, как мне кажется, недостаток — в описании Creator:
Второе утверждение основывается на постулате, который приходится принимать «как есть», безо всякого обоснования, почему объекты будут создаваться верно при следовании рекомендациям паттерна?
Небольшой, как мне кажется, недостаток — в описании Creator:
Шаблон creator говорит нам какие условия должны соблюстись, что бы объекты верно порождали друг друга. Для этого есть несколько правил:
...
… можно сделать вывод, что экземпляры класса Post должны создаваться внутри класса Blog, а Comment — в Post. Почему так а не иначе? Например, почему Comment не должны создаваться в Blog? Ну хотя бы потому, что именно Post содержит в себе экземпляры Comment, а так же Post обладает информацией для создания экземпляра Comment...
Второе утверждение основывается на постулате, который приходится принимать «как есть», безо всякого обоснования, почему объекты будут создаваться верно при следовании рекомендациям паттерна?
Это способ не запутаться в том, какой в итоге интерфейс в самого себя должен предоставлять создаваемый объект. Если мы точно знаем, что гвозди забиваются молотком, то нам ведь в голову не должно приходить использовать гвозди для соединения двух электрических цепей?
Излишество в интерфейсе, в общем, на сколько я понял. =)
Излишество в интерфейсе, в общем, на сколько я понял. =)
ОЧЕНЬ понравилось! Я прям в восторге, спасибо. ) Продолжайте, очень актуально. ) Как раз нахожусь сейчас где-то в районе той стадии, когда неприемлемо сразу кодировать, потому что жалко тратить свои силы на исправление ошибок потом )
Банду четырёх я тоже читал, но мне больше запомнилась другая книжка. Она более приближена к реалиям построения вэб-приложения. В ней обсуждаются такие интересные для вэб-разработчика вопросы как загрузка/сохранение объектов из/в базу данных, MVC (не в том виде, как это обсасывается на хабре «Посмотрите, дети!.. Какое чудо!»), расслоение системы.
Мартин Фаулер «Архитектура корпоративных программных приложений»
Мартин Фаулер «Архитектура корпоративных программных приложений»
Бесподобно! Продолжайте! Именно то, что сейчас нужно!
Когда то эта статья мне очень помогла :) надеюсь и здесь пригодится
www.citforum.ru/SE/project/pattern/
www.citforum.ru/SE/project/pattern/
Согласно книжке «Технологии разработки программного обеспечения» (С.А.Орлов) термины «coupling» и «cohesion» переводятся ровно наоборот, а именно:
cohesion — связность
coupling — сцепление
cohesion — связность
coupling — сцепление
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ООП для ООП: GRASP