Имея уже немалый опыт проектировщика и программиста, я надеялся найти в книге, как минимум, более проработанный вариант приёмов, использованных в предшествующих проектах. Достаточно быстро я обнаружил, что за многолетнюю практику большинство описанных авторами шаблонов было совершенно невостребованным кругом решаемых задач. Те же оставшиеся, что удалось идентифицировать, несколько удивили простотой и не всегда отражающими суть названиями.
Полагаю, что для человека, знакомого с основами ООП, вынести зависящую от контекста операции логику в специализированные обработчики или даже в классы, имеющие единый интерфейс вызова, является несложной операцией, над которой придётся раздумывать несколько минут. Например, часто такая задачка возникает в разного рода генераторах, когда по исходной модели нужно выдать код на том или ином языке программирования. Видимо поэтому, мне и не приходило в голову величать такую операцию «стратегией». Не ассоциировалась у меня тактическая перестановка фигур на шахматной доске со столь солидным термином.
Зачастую, ещё вчерашние новички, научившись достаточно элементарным вещам, любят порассуждать о том, что изобретение велосипедов – пустое дело. По моим представлениям на воспроизведение большинства из приводимых в книжке «велосипедов» в конкретных случаях у любого специалиста с навыками абстрактного мышления вряд ли должно уходить более часа. Это заметно быстрее изучения самой книги, ее осмысления и, наконец, осознания тех моментов, когда, собственно, надо применить абстрактный слепок в реальной жизни.
Распространённое мнение о создании некоей общей терминологии для повседневной работы программистов также не вполне подтвердилось на практике. В используемых спецификациях названиям шаблонов не находилось места. Обычно там пишется что-то вроде «реализовать документы с такими-то атрибутами, используя следующие базовые классы фреймворка» для новичка либо «реализовать функции А, Б, и В учёта договоров, используя модули X, Y и Z» для более опытного разработчика. Дело в том, что шаблоны из книги – уровня реализации и к моделированию предметной области имеют далёкое отношение. Они востребованы скорее теми, кто программирует (не хочу писать «кодирует») в группе, руководствуясь общей для всех подробной функциональной спецификацией. «Вася, здесь я сделаю адаптер над твоим классом, чтобы не напрягать тебя. – Да, Петя, спасибо». О том же, что класс имеет всего один экземпляр объекта, то есть является «синглетоном», Петя сможет догадаться по интерфейсу и без дополнительного вопроса Васе.
Факт защиты одним из авторов научной диссертации по теме книги заставил в очередной раз призадуматься о степени проникновения современной теоретической мысли в практику софтостроения. По моим представлениям, книга имела к науке весьма опосредованное отношение и являлась скорее чем-то вроде поваренной книги. Но лучше так, чем никак. Для себя же сделал вывод: если вы практикуете уже лет 5–10, то имеет смысл пролистать книжку и отложить, понадеявшись на фоновую память. Вдруг кто-то ввернёт в беседе незнакомый термин – меньше времени уйдёт на выяснение, что имелось в виду. На практике же толку будет немного.
Сложнее обстоит дело с теми, кто только начинает свой путь. Прочтение сего труда новичком, как мне кажется, является прямым аналогом попадания в прокрустово ложе диктуемой парадигмы. Потому что книга описывает набор решений, а неокрепшему за недостатком практики уму проектировщика надо научиться самому находить такие решения и пути к ним. Для чего гораздо эффективнее первое время «изобретать велосипеды», нежели сразу смотреть на готовые чужие. На чужие надо смотреть, когда придуман хотя бы один собственный, чтобы понять, насколько он несовершенен, и выяснить, каким же путём можно было бы прийти к лучшим образцам велосипедов данной модели.
Однако книга все-таки дала всплеск, и по воде пошли круги. А. Алексан-дреску в книге «Modern C++ design» начал экспериментировать с реализацией шаблонов на C++ и продвигать в массы свои велосипеды. Появились издания с достаточно абсурдными названиями. Например, «Шаблоны на C#». Постойте, коллеги, какие ещё шаблоны на C#? Оказывается, шаблоны сыграли с программистским сообществом злую шутку: они оказались ещё и зависимыми от языка программирования. То есть, прочитав «банду четырёх», писавших свой труд исходя из возможностей C++, срочно бегите за новой порцией информации, кто для Java, кто для C#. Хотя задумывались шаблоны с обобщающей практики целью.
Поясню на примере использования шаблона Visitor. У Александреску в самом начале описания шагов по применению шаблона на существующей иерархии классов документов, которую нужно наделить новыми функциональными возможностями (в примере шла речь о сборе статистики), в качестве отправной точки приводится следующий код:
Линейный способ
void DocStats::UpdateStats(DocElement& elem)
{
if (Paragraph* p = dynamic_cast
{
chars_ += p->NumChars();
words_ += p->NumWords();
}
else if (dynamic_cast
{
++images_;
}
else…