Когда книжку "Design patterns" банды четырех переводили на русский, случился небольшой казус.

Дело в том, что в английском языке для нашего слова "шаблон" есть целых два слова — pattern и template, и они имеют несколько разный смысл.
pattern — это то, что используется для распознавания. В большой куче информации ищут нужное с помощью паттерна. Например, регулярное выражение — это паттерн.
template — это то, на основе чего что-то генерируют. Отчеты можно формировать на основе шаблонов-template. Шаблоны отправляемых писем — это тоже templates.

Так вот книга называется "Design Patterns". То есть сборник паттернов для распознавания известных конструкций. Конечно простому переводчику сложно заметить такие тонкости, поэтому в нашем переводе паттерны стали сначала шаблонами, а потом и вовсе (о ужас!) приемами.

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

А все почему? Потому что домысливают: "код написанный с помощью приема из умной книжки безусловно лучше кода написанного без этого приема". Другими словами воспринимают паттерны как template-ы, и пытаются на их основе сгенерировать код своей программы.

После этого так и хочется обвинить банду четырех в запудривании неокрепших программистских мозгов. Но потом открываешь книжку, перечитываешь и оказывается, что никакого запудривания там нет. В книге все написано очень честно, четко и аккуратно. Задача книги — всего лишь дать разработчикам общий язык. Паттерн у них — это в первую очередь описание проблемы. И четкого описания проблемы для хоть сколько-то опытного разработчика достаточно, чтобы изобрести решение самостоятельно. Описание проблемы — это самое главное, что нужно запомнить из этой книжки! Но это первое, что обычно забывают после прочтения. Зато диаграммы классов все зазубривают наизусть.

Ярче всего это заметно на паттерне Посетитель. Какую он задачу решает? Обход дерева? Да ну вы бросьте! Обход дерева решается простым обходом дерева в глубину. Нечего придумывать замудрённых посетителей. Так какую же тогда?

А вот какую: У нас имеется довольно сложная составная структура данных (дерево, например), и эта структура меняется относительно редко. И есть набор операций, которые очень похожи (обходят структуру в одинаковом порядке), но при этом делают немного разные вещи. И главная беда в том, что таких операций много и постоянно появляются новые. Задача — сделать так, чтобы добавление новой операции не приводило к необходимости менять код уже написанных ранее классов.

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

Забавно, что я вот пишу сейчас это все, и мне это кажется совершенно очевидным. А с другой стороны я отчетливо помню период в своей жизни, когда я вот точно также пытался засовывать в свой код как можно больше паттернов, потому что "это же написано в умной книжке!"

Надеюсь этот мой пост ускорит у кого-нибудь выход из этой разрушительной фазы.