Когда книжку "Design patterns" банды четырех переводили на русский, случился небольшой казус.
Дело в том, что в английском языке для нашего слова "шаблон" есть целых два слова — pattern и template, и они имеют несколько разный смысл.
pattern — это то, что используется для распознавания. В большой куче информации ищут нужное с помощью паттерна. Например, регулярное выражение — это паттерн.
template — это то, на основе чего что-то генерируют. Отчеты можно формировать на основе шаблонов-template. Шаблоны отправляемых писем — это тоже templates.
Так вот книга называется "Design Patterns". То есть сборник паттернов для распознавания известных конструкций. Конечно простому переводчику сложно заметить такие тонкости, поэтому в нашем переводе паттерны стали сначала шаблонами, а потом и вовсе (о ужас!) приемами.
В результате имеем то, что имеем. Все пытаются втиснуть свою программу в известные им паттерны. Вместо обхода дерева в глубину втыкают в паттерн Посетитель. Вместо нормальной работы с зависимостями гордо рассыпают по коду множество синглтонов. Плодят фабрики. Обвешиваются декораторами.
А все почему? Потому что домысливают: "код написанный с помощью приема из умной книжки безусловно лучше кода написанного без этого приема". Другими словами воспринимают паттерны как template-ы, и пытаются на их основе сгенерировать код своей программы.
После этого так и хочется обвинить банду четырех в запудривании неокрепших программистских мозгов. Но потом открываешь книжку, перечитываешь и оказывается, что никакого запудривания там нет. В книге все написано очень честно, четко и аккуратно. Задача книги — всего лишь дать разработчикам общий язык. Паттерн у них — это в первую очередь описание проблемы. И четкого описания проблемы для хоть сколько-то опытного разработчика достаточно, чтобы изобрести решение самостоятельно. Описание проблемы — это самое главное, что нужно запомнить из этой книжки! Но это первое, что обычно забывают после прочтения. Зато диаграммы классов все зазубривают наизусть.
Ярче всего это заметно на паттерне Посетитель. Какую он задачу решает? Обход дерева? Да ну вы бросьте! Обход дерева решается простым обходом дерева в глубину. Нечего придумывать замудрённых посетителей. Так какую же тогда?
А вот какую: У нас имеется довольно сложная составная структура данных (дерево, например), и эта структура меняется относительно редко. И есть набор операций, которые очень похожи (обходят структуру в одинаковом порядке), но при этом делают немного разные вещи. И главная беда в том, что таких операций много и постоянно появляются новые. Задача — сделать так, чтобы добавление новой операции не приводило к необходимости менять код уже написанных ранее классов.
Выделю ключевые места: структура стабильна, структуру операции обходят одинаково, операций много и постоянно добавляются новые.
И вот только в этих условиях для обхода графа можно задуматься о посетителе.
Забавно, что я вот пишу сейчас это все, и мне это кажется совершенно очевидным. А с другой стороны я отчетливо помню период в своей жизни, когда я вот точно также пытался засовывать в свой код как можно больше паттернов, потому что "это же написано в умной книжке!"
Надеюсь этот мой пост ускорит у кого-нибудь выход из этой разрушительной фазы.
Здравствуйте, XopoSHiy, Вы писали:
XSH>Вместо обхода дерева в глубину втыкают в паттерн Посетитель.
XSH>Ярче всего это заметно на паттерне Посетитель. Какую он задачу решает? Обход дерева? Да ну вы бросьте! Обход дерева решается простым обходом дерева в глубину.
Здравствуйте, XopoSHiy, Вы писали:
XSH>Дело в том, что в английском языке для нашего слова "шаблон" есть целых два слова — pattern и template, и они имеют несколько разный смысл. XSH>pattern — это то, что используется для распознавания. В большой куче информации ищут нужное с помощью паттерна. Например, регулярное выражение — это паттерн. XSH>template — это то, на основе чего что-то генерируют. Отчеты можно формировать на основе шаблонов-template. Шаблоны отправляемых писем — это тоже templates.
In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.
Здравствуйте, XopoSHiy, Вы писали:
XSH>Дело в том, что в английском языке для нашего слова "шаблон" есть целых два слова — pattern и template, и они имеют несколько разный смысл. XSH>pattern — это то, что используется для распознавания. В большой куче информации ищут нужное с помощью паттерна. Например, регулярное выражение — это паттерн.
Очень спорное утверждение. Pattern — это образец. То, что задача распознавания часто сводится к поиску знакомого образца (например, регулярного выражения) — не проблемма образца и не проблема перевода.
Шаблоны проектирования — это примеры решения типичных задач. Собственно Кристофер Александер вряд ли занимался ими для того, чтобы архитектор, стоя посреди тихого северного города и глядя на дом культуры, мог сказать: "о, да это же типичное здание для северных широт!".
Насколько я помню, "банда" в своей книжке специально обращает внимание на то, что это не сборник готовых решений, и что до их применения надо немножко дорасти. Ну а с тем, что набор типичных решений помогает разным людям оперировать общеизвестными понятиями, сложно спорить.
www.translate.ru переводит pattern как образец. Не шаблон, а именно образец.
Иными словами , "Design Patterns" — это образцы программирования. Иными словами, примеры решения в некоторых ситуациях. И не более.
И тогда все становится на свои места. Это просто образцы того, как можно запрограммировать в той или иной более или менее стандартной ситуации. И образцов таких может быть много, вообще говоря — сколько угодно, от набора ситуаций зависит. Если у кого-то имеется ситуация, существенно отличная от тех, что есть в этой книге или вообще где бы то н было, то надо для нее придумать свое решение, которое и станет образцом для этой ситуации, если, конечно, будет реализовано как следует.
XSH>В результате имеем то, что имеем. Все пытаются втиснуть свою программу в известные им паттерны. Вместо обхода дерева в глубину втыкают в паттерн Посетитель. Вместо нормальной работы с зависимостями гордо рассыпают по коду множество синглтонов. Плодят фабрики. Обвешиваются декораторами.
Совершенно верно. Есть два способа что-то сделать. Первый — подумать и сделать. Второй — найти готовое решение и приспособить. Плохого во втором решении ничего нет. Так что если ситуация как раз подпадает под один из образцов, а для него есть хорошее проверенное решение, то почему бы и не взять ? Другое дело, что не надо тянуть ситуацию под этот образец, если она туда не лезет. В общем, просто думать надо.
XSH>А все почему? Потому что домысливают: "код написанный с помощью приема из умной книжки безусловно лучше кода написанного без этого приема". Другими словами воспринимают паттерны как template-ы, и пытаются на их основе сгенерировать код своей программы.
Верно. Просто думать надо
XSH>Забавно, что я вот пишу сейчас это все, и мне это кажется совершенно очевидным. А с другой стороны я отчетливо помню период в своей жизни, когда я вот точно также пытался засовывать в свой код как можно больше паттернов, потому что "это же написано в умной книжке!"
Я помню времена, когда ни о каких паттернах и речи не было. Когда я о них услышал, я решил посмотреть, что это такое. Ну в самом деле — шуму много, неужели там что-то революционное придумали ? Почитал — поулыбался. Большая часть тех образцов, что там есть (не все) мне были и раньше известны, вот только паттернами их никто не называл. И дошел я до них либо просто сам, придумывая подходящее решение, либо подсмотрел в чьем-то коде.
Здравствуйте, XopoSHiy, Вы писали:
XSH>Выделю ключевые места: структура стабильна, структуру операции обходят одинаково, операций много и постоянно добавляются новые. XSH>И вот только в этих условиях для обхода графа можно задуматься о посетителе.
обход может меняться, и не всякая структура годится потому ключевые моменты я бы сформулировал иначе
1. наличие структуры(Object structure)
а. которая сама по себе сложна
б. которая может состоять из объектов в разных иерархиях
2. структура оная стабильна
3. операции над этой структурой (а не отдельными объектами) много
а. операции не требуют экзотики
б. и нужно добавлять оные
А вообще хватает примеров в этом форуме про "без пяти минут" визитор.
Основной недостаток визитора вобщем то не в сложности добавления новых типов в иерархию, а в сложности изменения, преобразования и тд кода.
Код завязаный на визитор крайне сложно рефакторить, а буде необходимость избавиться от визитора, это сделать адски сложно, т.е. реально не бывает стабильных структур, они стабильны только в какой то определенной фазе.
Здравствуйте, Ikemefula, Вы писали:
I>обход может меняться, и не всякая структура годится потому ключевые моменты я бы сформулировал иначе
Ради эффектности я пожертвовал точностью описания визитора. Так что даже спорить не буду — не о том ведь тема.
Здравствуйте, XopoSHiy, Вы писали:
XSH>А вот какую: У нас имеется довольно сложная составная структура данных (дерево, например), и эта структура меняется относительно редко. И есть набор операций, которые очень похожи (обходят структуру в одинаковом порядке), но при этом делают немного разные вещи. И главная беда в том, что таких операций много и постоянно появляются новые. Задача — сделать так, чтобы добавление новой операции не приводило к необходимости менять код уже написанных ранее классов.
XSH>Выделю ключевые места: структура стабильна, структуру операции обходят одинаково, операций много и постоянно добавляются новые. XSH>И вот только в этих условиях для обхода графа можно задуматься о посетителе.
Ты сам неверно понимаешь, что такое визитор. Обход к визитору никакого отношения не имеет, это совсем другая задача, для которой есть другие паттерны (тот же итератор, к примеру). Задача визитора — обеспечение внешней по отношению к иерархии наследования диспетчеризации. Из того же флакона — мультиметоды и паттерн матчинг.
... << RSDN@Home 1.2.0 alpha 4 rev. 1471 on Windows 7 6.1.7600.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Ты сам неверно понимаешь, что такое визитор. Обход к визитору никакого отношения не имеет, это совсем другая задача, для которой есть другие паттерны (тот же итератор, к примеру). Задача визитора — обеспечение внешней по отношению к иерархии наследования диспетчеризации. Из того же флакона — мультиметоды и паттерн матчинг.
Просто я ради наглядности пожертвовал общностью (все же визитор обычно всплывает в задаче обхода дерева).
В целом полностью согласен, но суть от этого обобщения не меняется. Внешняя диспетчеризация осмысленна когда операций много, а иерархия более-менее стабильна. Если операций заведомо мало, то как правило нет смысла делать ее внешней. Если иерархия меняется часто, то визиторы (как и конструкции паттерн-матчинга) надо постоянно перекурочивать и допиливать. Множественная диспетчеризация (в частности мультиметоды), со всеми своими недостатками оказывается на коне, когда меняется и то и другое.
Суть в том, чтобы плясать от четкого понимания проблемы, а не от того, с какими паттернами ты знаком.
Здравствуйте, Pavel Dvorkin, Вы писали:
XSH>>А все почему? Потому что домысливают: "код написанный с помощью приема из умной книжки безусловно лучше кода написанного без этого приема". Другими словами воспринимают паттерны как template-ы, и пытаются на их основе сгенерировать код своей программы.
PD>Верно. Просто думать надо
Вот! Именно!
Я ведь не против применения паттернов в коде. Я за то чтобы думать головой!
PD>Я помню времена, когда ни о каких паттернах и речи не было. Когда я о них услышал, я решил посмотреть, что это такое. Ну в самом деле — шуму много, неужели там что-то революционное придумали ? Почитал — поулыбался. Большая часть тех образцов, что там есть (не все) мне были и раньше известны, вот только паттернами их никто не называл. И дошел я до них либо просто сам, придумывая подходящее решение, либо подсмотрел в чьем-то коде.
И по-моему, это самое правильное использование паттернов: узнать что как называется, чтобы потом легче было общаться с другими разработчиками. Все примерно так же как с UML.
Здравствуйте, XopoSHiy, Вы писали:
XSH>Просто я ради наглядности пожертвовал общностью (все же визитор обычно всплывает в задаче обхода дерева).
У тебя в тексте есть просто неверные утверждения. Никаких ограничений по способу обхода структуры для визитора нет. И графа, который нужно обходить, может просто не быть. Более тего, визитор, который сам пытается что то там обходить — в большинстве случаев неверное решение, так как вносит лишние ограничения без разумных обоснований.
XSH>Если операций заведомо мало, то как правило нет смысла делать ее внешней.
Я бы не был столь категоричным. Напихивание даже небольшого числа виртуальных методов в базовый класс, которые туда засунуты только ради диспетчеризации, далеко не всегда хорошая альтернатива визитору.
Вот стабильный состав конкретных наследников — это действительно требуется. Причем это ограничение не только визитора, но и, в какой то мере, и ПМ с алгебраическими типами. Это обратная сторона статического контроля за диспетчеризацией.
XSH> Если иерархия меняется часто, то визиторы (как и конструкции паттерн-матчинга) надо постоянно перекурочивать и допиливать.
Иногда это все же оправдано, так как любые альтернативные варианты переводят контроль в рантайм.
XSH>Суть в том, чтобы плясать от четкого понимания проблемы, а не от того, с какими паттернами ты знаком.
Ну, я говорил только про визитор.
... << RSDN@Home 1.2.0 alpha 4 rev. 1471 on Windows 7 6.1.7600.0>>
Здравствуйте, ZevS, Вы писали:
Dog>>Ну вот, ещё пару диаграмм и цитат из GoF и получится статья ZS>Книга. "Design Patterns Patterns".
или Designing Design Patterns. Никак выбрать не могу.
Здравствуйте, XopoSHiy, Вы писали:
XSH>Когда книжку "Design patterns" банды четырех переводили на русский, случился небольшой казус.
Никакого казуса. Авторы дают готовые шаблоны для недотумков, чтобы было чем махать на форумах, когда больше нечем.
XSH>... А с другой стороны я отчетливо помню период в своей жизни, когда я вот точно также пытался засовывать в свой код как можно больше паттернов
Это и есть главное зло "банды четырёх" — продавать набор рецептов, где все компоненты названы A, B, C... — кому такое фуфло нужно?
Даже средней руки программеру достаточно чётко сформулировать задачу, чтобы найти необходимое решение безо всяких GoF'оф.
Здравствуйте, matumba, Вы писали:
M>Никакого казуса. Авторы дают готовые шаблоны для недотумков, чтобы было чем махать на форумах, когда больше нечем. M>Это и есть главное зло "банды четырёх" — продавать набор рецептов, где все компоненты названы A, B, C... — кому такое фуфло нужно? M>Даже средней руки программеру достаточно чётко сформулировать задачу, чтобы найти необходимое решение безо всяких GoF'оф.
Согласен с наличием проблемы неправильного (а точнее чрезмерного) использования такого явления как Design Patterns, но не соглашусь с объяснением причин. И вот почему.
Преувеличение семантической значимости слова "шаблон"
На сегодняшний день у компьютерного термина "design pattern" существует как минимум несколько устойчивых переводов: 1. шаблон проектирования; 2. паттерн проектирования; 3. образец проектирования.
Критика термина "шаблон проектирования" (дескать, что переводчики книги "Design Patterns" допустили ошибку) необоснована, поскольку перевод был сделан не полгода назад, а десять лет назад и за это время компьютерное сообщество само "выбрало" наиболее подходящий вариант (и подкорректировало бы неудачный).
Второе замечание относится к семантике слова "шаблон". Во-первых, очень мало людей настолько серьезно вдумываются в тонкие семантические различия слов и терминов, ну а во-вторых: наши мозги, за счет изощренных средств распознавания образов, натренированы различать омонимичные сущности в контексте. Мы не путаем разные значения слова «коса», мы спокойно обходимся без буквы «ё» в слове «все» – за исключением тех случаев, когда контекст является недостаточным или двусмысленным.
Когда в воздухе произносится слово "шаблон", большинство людей не думает ни о чем, поскольку мозгу просто не хватает контекста, чтобы воссоздать соответствующий образ. Когда же к слову "шаблон" добавляется слово "C++", то в могу появляется образ "C++ Templates", если же к слову "шаблон" добавляется слово "проектирование", то в могу восстанавливается образ Design Patterns. Знающий человек понимает различие этих понятий и никогда их не спутает (точно также, если человек знает оба значения слова "коса", то он их не будет путать в правильных контекстах). Другое дело, если образ этот "подкачал" и у человека в мозгах неверная картина, он не правильно трактует понятие "Design Pattern" и не правильно его использует.
Правоверные
Я думаю, корень проблемы здесь несколько не в этом. Ведь если немного отойти в сторону, то легко можно заменить, что неправильное использование других инструментов (методологий, практик разработки, подходов, языков программирования и т.д.) также присутствует очень часто. Человек что-то понял, выучил и теперь старается прикрутить это куда можно и куда нельзя. Лучшим подтверждением тому является знаменитая цитата о том, что "молоток везде видит гвозди". Разве эта ситуация применима только к "Design Patterns"? Очень вряд ли.
Здесь гораздо более применима проблема, которую Демарко с компанией описали в одном из "шаблонов поведения" в книге "Adrenaline Junkies", они назвали таких людей "Правоверными" (True Belivers). (Кстати, в частности именно об этой проблеме, рассказывал один из соавторов упомянутой выше книги, Питер Хрущка на своем семинаре в Москве).
Идея этого шаблона (или паттерна, как хотите) сводится к следующему:
Человек принимает некую систему воззрений за евангелие. Малейшее отклонение от канона расценивается им как святотатство.
И хотя в нашем случае речь идет не о методах разработки, а о правильности применения некоторого подхода к проектированию (опять же, можно долго спорить о семантических различиях этих двух явлений), но все сводится к одной и той же проблеме:
Большинство руководств, посвященных процессу разработки (читай, шаблонам проектирования), честно предупреждают о границах применимости описываемых методов (читай, шаблонов проектирования), однако правоверный либо игнорирует эти предупреждения, либо просто не дочитыавет до них, поскольку эти страницы обычно расположены ближе к концу текста.
Здесь ситуация аналогичная. Вы же сами пишите, что Банда четырех говорит о применимости каждого шаблона, они пишут когда стоит им пользоваться, а когда нет. Но человек настолько увлекается, что использование шаблонов становится самоцелью, а не вспомогательным средством для решения его повседневных задач.
Аноглоязычное сообщество
Еще одним подтверждением того, что семантика слова шаблон здесь не причем служит шумиха в "англоязычном" компьютерном сообществе вокруг "Design Patterns". Там, на это понятие возлагались серьезные надежды, вы только посмотрите на количество книг, подкастов, журналов, конференций. Вы думаете у них шаблономании не было? Была, и там тоже отношение к шаблонам проектирования весьма неоднозначное: Design Patterns Considered Harmful.
Еще одним (и весьма ярким) подтверждением тому является один из последних подкастов Software Engineering Radio, в котором, кажется, Боб Мартин, стебется по этому поводу, что некоторые разработчики для написания программы "Hello, World" используют пять или шесть разных шаблонов проектирования.
Поэтому, будь причина в неправильном переводе или неверном трактовании семантических свойств слова "шаблон", эта проблема присутствовала бы только в русскоязычном сообществе, а в англоязычном ее бы не было по определению. Но это, увы, не так.
Здравствуйте, XopoSHiy, Вы писали:
XSH>Здравствуйте, AndrewVK, Вы писали:
AVK>>Ты сам неверно понимаешь, что такое визитор. Обход к визитору никакого отношения не имеет, это совсем другая задача, для которой есть другие паттерны (тот же итератор, к примеру). Задача визитора — обеспечение внешней по отношению к иерархии наследования диспетчеризации. Из того же флакона — мультиметоды и паттерн матчинг.
XSH>Просто я ради наглядности пожертвовал общностью (все же визитор обычно всплывает в задаче обхода дерева).
XSH>В целом полностью согласен, но суть от этого обобщения не меняется. Внешняя диспетчеризация осмысленна когда операций много, а иерархия более-менее стабильна. Если операций заведомо мало, то как правило нет смысла делать ее внешней. Если иерархия меняется часто, то визиторы (как и конструкции паттерн-матчинга) надо постоянно перекурочивать и допиливать. Множественная диспетчеризация (в частности мультиметоды), со всеми своими недостатками оказывается на коне, когда меняется и то и другое.
XSH>Суть в том, чтобы плясать от четкого понимания проблемы, а не от того, с какими паттернами ты знаком.
Бывает что и операций немного (даже и совсем одна), но "посетитель" отлично подходит (и, более того, неясно как сделать лучше без него). Имею пример из жизни. Есть общая для нескольких проектов библиотека LogicCoreLib, конкретный компонент проекта LogicCore, конкретное приложение App проекта (взаимодействует с пользователем — всяческие настройки и компоновка каких-то действий) и общая "визуальная" библиотека AppLib, которая тянет за собой "тяжелые" библиотеки, совсем не нужные для работы LogicCore и LogicCoreLib. В компонентах LogicCoreLib и LogicCore живут классы различной степени общности по отношению к имеющимся проектам (которые в LogicCoreLib — общие для всех, а которые в LogicCore — специфичны для одного проекта). Иерархия этих классов стабильна (может расти только в "ширину"). Нужно сделать "визуальную" работу с объектами этих классов в App внешней по отношению к ним. Поместить это в LogicCore нельзя, т.к. это потянет за собой зависимости от ненужных и "тяжелых" библиотек. По-моему это самое оно для применения посетителя. Пример на C#.
— кому такое фуфло нужно?
