Бьерн Страуструп (947334), страница 77
Текст из файла (страница 77)
одной реализации, но не достаточно общими, чтобы войти в
интерфейс. Например, поскольку в произвольном множестве нет
упорядоченности, в интерфейс set нельзя включать операцию
индексирования, даже если для реализации конкретного множества
используется массив. Это приводит к ухудшению характеристик программы
из-за отсутствия ручной оптимизации. Далее, становится как правило
невозможной реализация функций подстановкой (если не считать каких-то
конкретных ситуаций, когда настоящий тип известен транслятору), поэтому
все полезные операции интерфейса, задаются как вызовы
виртуальных функций. Как и для конкретных типов здесь плата за
абстрактные типы иногда приемлема, иногда слишком высока.
Подводя итог, перечислим каким целям должен служить абстрактный тип:
[1] определять некоторое понятие таким образом, что в программе
могут сосуществовать для него несколько реализаций;
[2] применяя виртуальные функции, обеспечивать достаточно высокую
степень компактности и эффективности выполнения программы;
[3] сводить к минимуму зависимость любой реализации от других
классов;
[4] представлять само по себе осмысленное понятие.
Нельзя сказать, что абстрактные типы лучше конкретных типов, это
просто другие типы. Какие из них предпочесть - это, как правило,
трудный и важный вопрос для пользователя. Создатель библиотеки может
уклониться от ответа на него и предоставить варианты с обеими типами,
тем самым выбор перекладывается на пользователя. Но здесь важно ясно
понимать, с классом какого вида имеешь дело. Обычно неудачей
заканчивается попытка ограничить общность абстрактного типа, чтобы
скорость программ, работающих с ним, приблизилась к скорости программ,
рассчитанных на конкретный тип. В этом случае нельзя
использовать взаимозаменяемые реализации без большой перетрансляции
программы после внесения изменений. Столь же неудачна бывает
попытка дать "общность" в конкретных типах, чтобы они могли по
мощности понятий приблизиться к абстрактным типам. Это снижает
эффективность и применимость простых классов. Классы этих двух видов
могут сосуществовать, и они должны мирно сосуществовать в программе.
Конкретный класс воплощает реализацию абстрактного типа, и смешивать
его с абстрактным классом не следует.
Отметим, что ни конкретные, ни абстрактные типы не создаются
изначально как базовые классы для построения в дальнейшем производных
классов. Построение производных к абстрактным типам классов
скорее нужно для задания реализаций, чем для развития самого понятия
интерфейса. Всякий конкретный или абстрактный тип предназначен для четкого
и эффективного представления в программе отдельного понятия. Классы,
которым это удается, редко бывают хорошими кандидатами для создания
на их базе новых, но связанных с ними, классов. Действительно, попытки
построить производные, "более развитые" классы на базе конкретных или
абстрактных типов, таких как, строки, комплексные числа, списки или
ассоциативные массивы приводят обычно к громоздким конструкциям.
Как правило эти классы следует использовать как члены или частные базовые
классы, тогда их можно эффективно применять, не вызывая путаницы и
противоречий в интерфейсах и реализациях этих и новых классов.
Когда создается конкретный или абстрактный тип, акцент следует
сделать на том, чтобы предложить простой, реализующий хорошо
продуманное понятие, интерфейс. Попытки расширить область приложения
класса, нагружая его описание всевозможными "полезными" свойствами,
приводят только к беспорядку и неэффективности. Этим же кончаются
напрасные усилия гарантировать повторное использование класса, когда
каждую функцию-член объявляют виртуальной, не подумав зачем и как
эти функции будут переопределяться.
Почему мы не стали определять классы slist и vector как прямые
производные от класса set, обойдясь тем самым без классов slist_set
и vector_set? Другими словами зачем нужны конкретные типы, когда уже
определены абстрактные типы? Можно предложить три ответа:
[1] Эффективность: такие типы, как vector или slist надо создавать
без накладных расходов, вызванных отдалением реализаций
от интерфейсов (разделения интерфейса и реализации требует
концепция абстрактного типа).
[2] Множественный интерфейс: часто разные понятия лучше всего
реализовать как производные от одного класса.
[3] Повторное использование: нужен механизм, который позволит
приспособить для нашей библиотеки типы, разработанные
"где-то в другом месте".
Конечно, все эти ответы связаны. В качестве примера [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 описывается более гибкий итератор. Для него
зависимость от реализации, которая поставляет подлежащие итерации
объекты, определяется в момент инициализации и может изменяться в ходе
выполнения программы.
13.4 Узловые классы
В действительности иерархия классов строится, исходя из совсем другой
концепции производных классов, чем концепция интерфейс-реализация,
которая использовалась для абстрактных типов. Класс рассматривается
как фундамент строения. Но даже, если в основании находится абстрактный
класс, он допускает некоторое представление в программе и сам предоставляет
для производных классов какие-то полезные функции. Примерами узловых
классов могут служить классы rectangle ($$6.4.2) и satellite ($$6.5.1).
Обычно в иерархии класс представляет некоторое общее понятие, а
производные классы представляют конкретные варианты этого понятия.
Узловой класс является неотъемлемой частью иерархии классов. Он пользуется
сервисом, представляемым базовыми классами, сам обеспечивает определенный
сервис и предоставляет виртуальные функции и (или) защищенный
интерфейс, чтобы позволить дальнейшую детализацию своих операций в
производных классах.
Типичный узловой класс не только предоставляет реализацию
интерфейса, задаваемого его базовым классом (как это делает класс
реализации по отношению к абстрактному типу), но и сам расширяет
интерфейс, добавляя новые функции. Рассмотрим в качестве примера
класс dialog_box, который представляет окно некоторого вида на экране.
В этом окне появляются вопросы пользователю и в нем он задает свой
ответ с помощью нажатия клавиши или "мыши":
class dialog_box : public window {
// ...
public:
dialog_box(const char* ...); // заканчивающийся нулем список
// обозначений клавиш
// ...
virtual int ask();
};
Здесь важную роль играет функция ask() и конструктор, с помощью которого
программист указывает используемые клавиши и задает их числовые значения.
Функция ask() изображает на экране окно и возвращает номер нажатой в ответ
клавиши. Можно представить такой вариант использования:
void user()
{
for (;;) {
// какие-то команды
dialog_box cont("continue",
"try again",
"abort",
(char*) 0);
switch (cont.ask()) {
case 0: return;
case 1: break;
case 2: abort();
}
}
}
Обратим внимание на использование конструктора. Конструктор, как
правило, нужен для узлового класса и часто это нетривиальный
конструктор. Этим узловые классы отличаются от абстрактных классов,
для которых редко нужны конструкторы.
Пользователь класса dialog_box ( а не только создатель этого
класса) рассчитывает на сервис, представляемый его базовыми классами.
В рассматриваемом примере предполагается, что существует
некоторое стандартное размещение нового окна на экране. Если
пользователь захочет управлять размещением окна, базовый для
dialog_box класс window (окно) должен предоставлять такую возможность,
например:
dialog_box cont("continue","try again","abort",(char*)0);
cont.move(some_point);
Здесь функция движения окна move() рассчитывает на определенные
функции базовых классов.
Сам класс dialog_box является хорошим кандидатом для построения
производных классов. Например, вполне разумно иметь такое окно,
в котором, кроме нажатия клавиши или ввода с мышью, можно задавать
строку символов (скажем, имя файла). Такое окно dbox_w_str строится
как производный класс от простого окна dialog_box:
class dbox_w_str : public dialog_box {
// ...
public:
dbox_w_str (
const char* sl, // строка запроса пользователю
const char* ... // список обозначений клавиш
);
int ask();
virtual char* get_string();
//...
};
Функция get_string() является той операцией, с помощью
которой программист получает заданную пользователем строку. Функция
ask() из класса dbox_w_str гарантирует, что строка введена правильно,
а если пользователь не стал вводить строку, то тогда в программу
возвращается соответствующее значение (0).
void user2()
{
// ...
dbox_w_str file_name("please enter file name",
"done",
(char*)0);
file_name.ask();
char* p = file_name.get_string();
if (p) {
// используем имя файла
}
else {
// имя файла не задано
}
//
}
Подведем итог - узловой класс должен:
[1] рассчитывать на свои базовые классы как для их реализации,
так и для представления сервиса пользователям этих классов;
[2] представлять более полный интерфейс (т.е. интерфейс с большим
числом функций-членов) пользователям, чем базовые классы;
[3] основывать в первую очередь (но не исключительно) свой
общий интерфейс на виртуальных функциях;
[4] зависеть от всех своих (прямых и косвенных) базовых классов;
[5] иметь смысл только в контексте своих базовых классов;
[6] служить базовым классом для построения производных классов;
[7] воплощаться в объекте.
Не все, но многие, узловые классы будут удовлетворять условиям
1, 2, 6 и 7. Класс, который не удовлетворяет условию 6, походит
на конкретный тип и может быть назван конкретным узловым классом.
Класс, который не удовлетворяет условию 7, походит на абстрактный
тип и может быть назван абстрактным узловым классом. У многих
узловых классов есть защищенные члены, чтобы предоставить для
производных классов менее ограниченный интерфейс.
Укажем на следствие условия 4: для трансляции своей программы
пользователь узлового класса должен включить описания всех его
прямых и косвенных базовых классов, а также описания
всех тех классов, от которых, в свою очередь, зависят базовые классы.
В этом узловой класс опять представляет контраст с абстрактным типом.
Пользователь абстрактного типа не зависит от всех классов,
использующихся для реализации типа и для трансляции своей программы
не должен включать их описания.
13.5 Динамическая информация о типе
Иногда бывает полезно знать истинный тип объекта до его использования
в каких-либо операциях. Рассмотрим функцию my(set&) из $$13.3.
void my_set(set& s)
{
for ( T* p = s.first(); p; p = s.next()) {
// мой код
}
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
