Грани

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

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

protected:

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

public:

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

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

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

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

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

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

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

};

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

обладают своими недостатками.

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

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

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

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

слабонервных.

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

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

class ViewEvents {

private:

View* view;

public:

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

};

class ViewDrawing {

private:

View* view;

public:

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

};

// И т.д.

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

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

ни назывались, этой идее суждено стать одной из важнейших идиом дизайна объектно-

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

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