Знакомство с такими дизайнами, как TrashVisitor.java, который содержит большое количество кода, по сравнению с ранними дизайнами, может показаться, что они контрпродуктивны. Это плата за то, чтобы заметить, что вы пробуете совершить с различными вариантами дизайна. Шаблоны дизайна в основном стараются отделить вещи, которые меняются от вещей, которые остаются теми же самыми. "Вещи, которые меняются" могут соотноситься со многими другими видами изменений. Возможно, изменения происходят по причине помещения программы в новое окружения или потому, что что-то в текущем окружении поменялось (это может быть: "Пользователь хочет добавить новый образ в диаграмму, находящуюся на экране"). Или, как в этом случае, TrashVisitor.java позволяет вам совершать эволюцию тела кода. Пока предыдущие версии примеров сортировки мусора акцентировали внимание на добавлении новых типов Мусора в систему, TrashVisitor.java позволил вам облегчить добавление функциональности без разрушения иерархии Мусора. В TrashVisitor.java есть гораздо больше кода, но добавление новой функциональности в Visitor не сложно. Если это происходит очень часто, то с этой сточки зрения дополнительный объем работ и дополнительный код сделает такую работу легче.

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

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

Шаблоны дизайнов говорят, что ООП это не все, что относится к полиморфизму. Это "отделение вещей, которые меняются, от вещей, которые остаются теми же самыми". Полиморфизма особенной важный путь, чтобы сделать это, и он приносит пользу, если язык программирования напрямую поддерживает полиморфизм (так что вам не нужно изабретать его самостоятельно, что может стать чрезвычайно дорогим занятием). Но шабоны дизайна в своей основе показывают другие пути достижения основной цели, и если ваши глаза открыты, вы начнете искать более креативные дизайны.

Так как появление книги "Design Patterns" послужило толчком, люди стали искать шаблоны. Вы можете ожидать появление все большего числа шаблонов с течением времени. Вот некоторые сайты, рекомендованные Джимом Коуплиеном (Jim Coplien), известного в C++ (http://www.bell-labs.com/~cope), являющегося главным пропагандистом продвижения шаблонов:

http://st-www.cs.uiuc.edu/users/patterns
http://c2.com/cgi/wiki
http://c2.com/ppr
http://www.bell-labs.com/people/cope/Patterns/Process/index.html
http://www.bell-labs.com/cgi-user/OrgPatterns/OrgPatterns
http://st-www.cs.uiuc.edu/cgi-bin/wikic/wikic
http://www.cs.wustl.edu/~schmidt/patterns.html
http://www.espinc.com/patterns/overview.html

Также обратите внимание на ежегодную конференцию по шаблонам дизайна, называемую PLOP, которая имеет публичную практику, треть которой идет позже 1997 (все опубликовано Addison-Wesley).

← RTTI относительно полезно? Упражнения →