|
|
Самый простой способ ослабить связь между пользователем класса и его создателем, а также между программами, в которых объекты создаются, и программами, в которых они используются, состоит в введении понятия абстрактных базовых классов. Эти классы представляют интерфейс со множеством реализаций одного понятия. Рассмотрим класс set, содержащий множество объектов типа T:
class set { public: virtual void insert(T*) = 0; virtual void remove(T*) = 0; virtual int is_member(T*) = 0; virtual T* first() = 0; virtual T* next() = 0; virtual ~set() { } };
Этот класс определяет интерфейс с произвольным множеством (set), опираясь на встроенное понятие итерации по элементам множества. Здесь типично отсутствие конструктора и наличие виртуального деструктора, см. также $$6.7. Рассмотрим пример:
class slist_set : public set, private slist { slink* current_elem; public: void insert(T*); void remove(T*); int is_member(T*); virtual T* first(); virtual T* next(); slist_set() : slist(), current_elem(0) { } }; class vector_set : public set, private vector { int current_index; public: void insert(T*); void remove(T*); int is_member(T*); T* first() { current_index = 0; return next(); } T* next(); vector_set(int initial_size) : array(initial_size), current_index(0) { } };
Реализация конкретного типа используется как частный базовый
класс, а не член класса. Это сделано и для удобства записи, и потому,
что некоторые конкретные типы могут иметь защищенный интерфейс
с целью предоставить более прямой доступ к своим членам из производных
классов. Кроме того, подобным образом в реализации могут использоваться
некоторые классы, которые имеют виртуальные функции и не являются
конкретными типами. Только с помощью образования производных классов
можно в новом классе изящно переопределить (подавить) виртуальную
функцию класса реализации. Интерфейс определяется абстрактным классом.
Теперь пользователь может записать свои функции из $$13.2
таким образом:
void my(set& s) { for (T* p = s.first(); p; p = s.next()) { // мой код } // ... } void your(set& s) { for (T* p = s.first(); p; p = s.next()) { // ваш код } // ... }
Стало очевидным сходство между двумя функциями, и теперь достаточно иметь только одну версию для каждой из функций my() или your(), поскольку для общения с slist_set и vector_set обе версии используют интерфейс, определяемый классом set:
void user()
{
slist_set sl;
vector_set v(100);
my(sl);
your(v);
my(v);
your(sl);
}
Более того, создатели функций my() и your() не обязаны знать описаний
классов slist_set и vector_set, и функции my() и your() никоим
образом не зависят от этих описаний. Их не надо перетранслировать
или как-то изменять, ни если изменились классы slist_set или
vector_set ни даже, если предложена новая реализация этих классов.
Изменения отражаются лишь на функциях, которые непосредственно
используют эти классы, допустим vector_set. В частности, можно
воспользоваться традиционным применением заголовочных файлов и
включить в программы с функциями my() или your() файл определений
set.h, а не файлы slist_set.h или vector_set.h.
В обычной ситуации операции абстрактного класса задаются как
чистые виртуальные функции, и такой класс не имеет членов,
представляющих данные (не считая скрытого указателя на таблицу
виртуальных функций). Это объясняется тем, что добавление невиртуальной
функции или члена, представляющего данные, потребует определенных
допущений о классе, которые будут ограничивать возможные реализации.
Изложенный здесь подход к абстрактным классам близок по духу традиционным
методам, основанным на строгом разделении интерфейса и его реализаций.
Абстрактный тип служит в качестве интерфейса, а конкретные типы
представляют его реализации.
Такое разделение интерфейса и его реализаций предполагает
недоступность операций, являющихся "естественными" для какой-то
одной реализации, но не достаточно общими, чтобы войти в
интерфейс. Например, поскольку в произвольном множестве нет
упорядоченности, в интерфейс set нельзя включать операцию
индексирования, даже если для реализации конкретного множества
используется массив. Это приводит к ухудшению характеристик программы
из-за отсутствия ручной оптимизации. Далее, становится как правило
невозможной реализация функций подстановкой (если не считать каких-то
конкретных ситуаций, когда настоящий тип известен транслятору), поэтому
все полезные операции интерфейса, задаются как вызовы
виртуальных функций. Как и для конкретных типов здесь плата за
абстрактные типы иногда приемлема, иногда слишком высока.
Подводя итог, перечислим каким целям должен служить абстрактный тип:
Нельзя сказать, что абстрактные типы лучше конкретных типов, это
просто другие типы. Какие из них предпочесть - это, как правило,
трудный и важный вопрос для пользователя. Создатель библиотеки может
уклониться от ответа на него и предоставить варианты с обеими типами,
тем самым выбор перекладывается на пользователя. Но здесь важно ясно
понимать, с классом какого вида имеешь дело. Обычно неудачей
заканчивается попытка ограничить общность абстрактного типа, чтобы
скорость программ, работающих с ним, приблизилась к скорости программ,
рассчитанных на конкретный тип. В этом случае нельзя
использовать взаимозаменяемые реализации без большой перетрансляции
программы после внесения изменений. Столь же неудачна бывает
попытка дать "общность" в конкретных типах, чтобы они могли по
мощности понятий приблизиться к абстрактным типам. Это снижает
эффективность и применимость простых классов. Классы этих двух видов
могут сосуществовать, и они должны мирно сосуществовать в программе.
Конкретный класс воплощает реализацию абстрактного типа, и смешивать
его с абстрактным классом не следует.
Отметим, что ни конкретные, ни абстрактные типы не создаются
изначально как базовые классы для построения в дальнейшем производных
классов. Построение производных к абстрактным типам классов
скорее нужно для задания реализаций, чем для развития самого понятия
интерфейса. Всякий конкретный или абстрактный тип предназначен для четкого
и эффективного представления в программе отдельного понятия. Классы,
которым это удается, редко бывают хорошими кандидатами для создания
на их базе новых, но связанных с ними, классов. Действительно, попытки
построить производные, "более развитые" классы на базе конкретных или
абстрактных типов, таких как, строки, комплексные числа, списки или
ассоциативные массивы приводят обычно к громоздким конструкциям.
Как правило эти классы следует использовать как члены или частные базовые
классы, тогда их можно эффективно применять, не вызывая путаницы и
противоречий в интерфейсах и реализациях этих и новых классов.
Когда создается конкретный или абстрактный тип, акцент следует
сделать на том, чтобы предложить простой, реализующий хорошо
продуманное понятие, интерфейс. Попытки расширить область приложения
класса, нагружая его описание всевозможными "полезными" свойствами,
приводят только к беспорядку и неэффективности. Этим же кончаются
напрасные усилия гарантировать повторное использование класса, когда
каждую функцию-член объявляют виртуальной, не подумав зачем и как
эти функции будут переопределяться.
Почему мы не стали определять классы slist и vector как прямые
производные от класса set, обойдясь тем самым без классов slist_set
и vector_set? Другими словами зачем нужны конкретные типы, когда уже
определены абстрактные типы? Можно предложить три ответа:
Конечно, все эти ответы связаны. В качестве примера [2] рассмотрим
понятие генератора итераций. Требуется определить генератор
итераций (в дальнейшем итератор) для любого типа так, чтобы с его
помощью можно было порождать последовательность объектов этого типа.
Естественно для этого нужно использовать уже упоминавшийся класс slist.
Однако, нельзя просто определить общий итератор над slist, или даже
над set, поскольку общий итератор должен допускать итерации и более
сложных объектов, не являющихся множествами, например, входные потоки
или функции, которые при очередном вызове дают следующее значение итерации.
Значит нам нужны и множество и итератор, и в тоже время
нежелательно дублировать конкретные типы, которые являются очевидными
реализациями различных видов множеств и итераторов. Можно графически
представить желательную структуру классов так:
Здесь классы set и iter предоставляют интерфейсы, а slist и stream
являются частными классами и представляют реализации. Очевидно,
нельзя перевернуть эту иерархию классов и, предоставляя общие
интерфейсы, строить производные конкретные типы от абстрактных классов.
В такой иерархии каждая полезная операция над каждым полезным абстрактным
понятием должна представляться в общем абстрактном базовом классе.
Дальнейшее обсуждение этой темы содержится в $$13.6.
Приведем пример простого абстрактного типа, являющегося
итератором объектов типа T:
class iter { virtual T* first() = 0; virtual T* next() = 0; virtual ~iter() { } }; class slist_iter : public iter, private slist { slink* current_elem; public: T* first(); T* next(); slist_iter() : current_elem(0) { } }; class input_iter : public iter { isstream& is; public: T* first(); T* next(); input_iter(istream& r) : is(r) { } };
Можно таким образом использовать определенные нами типы:
void user(const iter& it) { for (T* p = it.first(); p; p = it.next()) { // ... } } void caller() { slist_iter sli; input_iter ii(cin); // заполнение sli user(sli); user(ii); }
Мы применили конкретный тип для реализации абстрактного типа, но
можно использовать его и независимо от абстрактных типов или просто
вводить такие типы для повышения эффективности программы,
см. также $$13.5. Кроме того, можно использовать один конкретный тип
для реализации нескольких абстрактных типов.
В разделе $$13.9 описывается более гибкий итератор. Для него
зависимость от реализации, которая поставляет подлежащие итерации
объекты, определяется в момент инициализации и может изменяться в ходе
выполнения программы.
| |
|
