Шаблон Visitor

в этой главе обсуждаются обобщенные компоненты, использующие щаблон проектирования visitor (Gamma et al., 1995). Это мощный щаблон проектирования, измешпо-щий зависимость между проектными решениями, принятыми при разработке класса.

Шаблон visitor (Инспектор) обеспечивает удивительную гибкость: в иерархию классов можно добавлять виртуальные функции, не прибегая к повторной компиляции ни этих функций, ни существующих клиентских кодов. Однако эта гибкость достигается за счет определенных жертв: в иерархию теперь невозможно добавить новый терминальный класс (leaf class), не повторив компиляцию всей иерархии и ее клиентов. Следовательно, область применения шаблона visitor ограничивается только очень устойчивыми иерархиями (в которые редко добавляются новые классы) и программами, в которые часто приходится добавлять новые виртуальные функции.

Шаблон Visitor противоречит программистской интуиции. Следовательно, для его успешного применения нужны тщательная реализация и строгая дисциплина. В главе описывается обобщенная реализация шаблона visitor, оставляющая прикладному программисту очень мало работы.

В главе обсуждаются следующие темы.

Принцип работы шаблона visitor.

Когда следует применять шаблон visitor и, что не менее важно, когда его применять не следует.

Базовая реализация инспектора (предложенная группой GoF).

Как устранить некоторые недостатки базовой реализации шаблона Visitor.

Как реализовать решения, касающиеся реализации шаблона Visitor, в виде библиотеки.

Мощные обобщенные компоненты, облегчающие реализацию инспекторов.

10.1. Основы шаблона Visitor

Рассмотрим иерархию классов, которую мы хотим наделить новыми функциональными возможностями. Для этого в нее можно добавлять либо новые классы, либо новые виртуальные функции-члены.

Добавить новые классы легко. Можно применить механизм наследования к терминальному классу и реализовать необходимые виртуальные функции. Для этого не нужно изменять или компилировать вновь существующие классы. Их коды остаются неизменными и готовы к повторному использованию.

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

Короче говоря, с точки зрения зависимостей между классами новые классы добавлять легко, а новые виртуальные функции-члены - трудно.

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

Шаблон Visitor лучще всего проявляет свои возможности, когда операции на объектами не связаны между собой. Парадигма состояние и операции для каждого класса становится не совсем уместной. В данной ситуации лучще придерживаться принципа отделения типов от операций. Имеет смысл хранить разные реализации одной операции вместе, а не распределять их по иерархии классов.

Допустим, что мы разрабатываем текстовый редактор. Элементы документа, такие как абзащ.1 и графические изображения, представляются в виде классов, производнь[х от одного базового класса, скажем, DocElement. Документ - это сфуктурированный набор указателей на объекты класса DocElement. Профаммисту нужна возможность перемещаться по этой сфуктуре и выполнять операции, например, проверку орфофафии, переформатирование и вычисление статистических показателей. В идеале следовало бы реализовывать эти операции, добавив новый код без модификации существующей профаммы. Более того, профамму было бы легче сопровождать, если бы весь код, связанный, скажем, с вычислением статистических показателей, хранился в одном месте.

К статистическим показателям могут относиться общее количество символов, значащих символов, слов и рисунков. Все это естественным образом можно поместить в класс DocStats.

class DocStats {

unsigned int, chars ,

nonBlankChars ,

words ,

images ;

public:

void AddChars(unsigned int charsToAdd) {

chars += charsToAdd; }

... классы Addwords, Addlmages и др. определяются так же ... Статистика отображается в диалоговом окне void DisplayО; };

Используя классический объектно-ориентированный подход к сбору статистики, можно определить в классе DocElement соответствующую виртуальную функцию.

class DocElement {

эта функция-член предназначена для сбора статистики virtual void updateStatsCDocStats& statistics) = 0;

В этом случае каждый конкретный элемент документа может определять эту функцию по-своему. Например, классы Paragraph и RasterBitmap, производные от класса DocElement, могут реализовывать функцию updateStats следующим образом.

void Paragraph::updateStatsCDocStats& statistics) {

statistics.AddCharsC/соугы/ес/яво символов в абзаце) ; statistics.AddwordsC/соугы/ес/яво слов в абзаце);

void RasterBitmap::updateStatsCDocStats& statistics) {

Этот класс учитывает только рисунки и больше ничего (символы и другие элементы игнорируются) statistics.Addlmages(l);

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

voi d Document::Di splayStati sti cs() {

DocStats statistics;

for (каждый элемент документа)

3yzejMeHm->updateStats(statistics); }

statistics .DisplayO;

Это очень хорощая реализация возможностей по сбору статистики, однако у нее есть ряд недостатков.

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

Фактические операции по сбору статистики рассеяны по разным реализациям функции UpdateStats. При отладке или расщирении возможностей, связанных со сбором статистики, придется искать и редактировать несколько файлов.

Реализация не масштабируется по мере добавления новых операций, аналогичных сбору статистики. Для того чтобы добавить операцию увеличить размер шрифта на один пункт , понадобится добавить в класс DocElement новую виртуальную функцию, преодолевая все связанные с этим трудности.

Однако связь, существующую между классами DocElement и DocStats, можно разорвать, если переместить все операции внутрь класса DocStats и позволить ему самому определять, какую операцию выполнять для того или иного типа. Для этого нужно, чтобы в