Видите, что здесь происходит? Для клиента класс Foo перестает существовать. Для всех практических целей указатель стал самим объектом. С таким же успехом мы могли все переименовать, убрать Р перед указателем и заменить имя Foo чем-нибудь более закрытым и загадочным. Единственное, что говорит о существовании второго класса, - предварительное объявление class Foo;.

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

Изменение интерфейса

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

Грани

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

class View { На практике будет производным от другого класса protected:

Часть, предназначенная только для производных классов вида public:

Функции конструирования и инициализации

Функции уничтожения и деактивизации

Общие функции объекта

Обработка событий

Функции отображения

Геометрия ( где сработала мышь? )

Управление иерархией видов

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

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

Когда фрагменты объединяются в общий класс, от которого затем создаются производные классы, проблема возникает заново на другом уровне иерархии классов.

Нелегко заставить один базовый класс правильно работать с другим, когда эти два класса не имеют ничего общего до их объединения в контексте некоторого составного класса.

Проектирование больших комплексов взаимодействующих объектов - занятие не для слабонервных.

Можно ли разбить такой класс на составляющие, не прибегая к сложностям создания производных классов или делегирования? Конечно можно, если воспользоваться технологией мудрых указателей. Достаточно создать для одного объекта несколько указателей, каждый из которых отвечает за некоторый аспект деятельности этого объекта.

class ViewEvents { private:

View* view; public:

Функции, относящиеся к обработке событий

class ViewDrawing { private:

View* view; public:

Функции, относящиеся к графическому выводу

И т.д.

Каждый из этих мудрых указателей воспроизводит интерфейс к некоторому подмножеству функций класса View и перенаправляет вызовы функциям-прототипам объекта вида. Сам объект вида может быть устроен как угодно: на основе одиночного и множественного наследования, делегирования в комплексе объектов или в форме одного гигантского конгломерата; клиентов это волновать не должно. Я называю такие интерфейсные указатели, ограничивающие клиента подмножеством полного интерфейса, гранями (facets).

Эта базовая идея укоренилась как минимум в одной коммерческой технологии - компонентной модели объекта (СОМ, Component Object Model) компании Microsoft, которая называет эти указатели интерфейсами. Один из мелких разработчиков, компания Quasar Knowledge Systems, предложила аналогичную идею для объектов SmallTalk и назвала такие указатели комплексами (suites). Как бы они ни назывались, этой идее суждено стать одной из важнейших идиом дизайна объектно-ориентированного программирования будущего, поскольку она обладает повышенной гибкостью и модульностью по сравнению с функциональным делением на основе наследования и делегирования.

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

Преобразование указываемого объекта в грань

Итак, вы хотите получить грань по имеющемуся указываемому объекту. Для этого существует много способов, однако наиболее соответствующий стилю C++ заключается в использовании операторов преобразования.

class View { public:

operator ViewEvents() { return new ViewEvents(this); } operator ViewDrawing() { return new ViewDrawing(this); }

Другой вариант - разрешить пользователю напрямую использовать конструкторы класса грани: ViewEvents ve(aView);

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

противном случае. Те из вас, кому приходилось пользоваться технологиями СОМ и OLE компании Microsoft, узнают знакомую функцию Querylnterface, поддерживаемую всеми объектами.

Кристаллы

Если у вас имеется одна грань и вы хотите получить другую грань того же объекта, наиболее прямолинейный подход также заключается во включении операторов преобразования в грань. Упрощенный подход выглядит так:

class ViewEvents { private:

View* view; public:

operator ViewDrawing() { return ViewDrawing(*view); } И т.д. для других граней

В этом маленьком С++-изме работа поручается операторной функции operator ViewDrawing() целевого вида. При малом количестве граней такое решение вполне приемлемо. С ростом количества граней число операторов преобразования возрастает в квадратичной зависимости, поскольку каждая грань должна преобразовывать ко всем остальным. Следующая модификация возвращает задачу к порядку n, где n - количество граней. Продолжая свою откровенно слабую метафору, я называю объект, который собирает и выдает грани, кристаллом (gemstone).

class View; class ViewEvents; class ViewDrawing; class ViewGemstone { private:

View* view; public:

ViewGemstone(View* v) : view(v) {}

bool operator!() { return view == NULL; }

operator ViewEvents();

operator ViewDrawing();

И т.д.

class ViewEvents {

friend class ViewGemstone;

private:

View* view;

ViewEvents(View* v) : view(v) {} public:

bool operator!() { return view == NULL; } operator ViewGemstone();

class ViewDrawing { friend class ViewGemstone; private:

View* view;

ViewDrawing(View* v) : view(v) {}