Бьерн Страуструп (Стpаустpуп - Книга о C++), страница 80

не упрощается, ведь полное тестирование затруднительно и требует

многих усилий .

Поэтому, если целью является программа с хорошими характеристиками,

или требуются высокие гарантии корректности программы, или, вообще,

есть хорошая альтернатива, лучше не использовать обширные интерфейсы.

Кроме того, использование обширного интерфейса нарушает

взаимнооднозначное соответствие между классами и понятиями, и тогда

начинают вводить новые производные классы просто для удобства

реализации.

13.7 Каркас области приложения

Мы перечислили виды классов, из которых можно создать библиотеки,

нацеленные на проектирование и повторное использование прикладных

программ. Они предоставляют определенные "строительные блоки" и

объясняют как из них строить. Разработчик прикладного обеспечения создает

каркас, в который должны вписаться универсальные строительные блоки. Задача

проектирования прикладных программ может иметь иное, более обязывающее

решение: написать программу, которая сама будет создавать общий каркас

области приложения. Разработчик прикладного обеспечения

в качестве строительных блоков будет встраивать в этот каркас

прикладные программы. Классы, которые образуют каркас области

приложения, имеют настолько обширный интерфейс, что их трудно

назвать типами в обычном смысле слова. Они приближаются к тому

пределу, когда становятся чисто прикладными классами, но при этом

в них фактически есть только описания, а все действия задаются

функциями, написанными прикладными программистами.

Для примера рассмотрим фильтр, т.е. программу, которая может

выполнять следующие действия: читать входной поток, производить

над ним некоторые операции, выдавать выходной поток и определять

конечный результат. Примитивный каркас для фильтра будет состоять

из определения множества операций, которые должен реализовать

прикладной программист:

class filter {

public:

class Retry {

public:

virtual const char* message() { return 0; }

};

virtual void start() { }

virtual int retry() { return 2; }

virtual int read() = 0;

virtual void write() { }

virtual void compute() { }

virtual int result() = 0;

};

Нужные для производных классов функции описаны как чистые виртуальные,

остальные функции просто пустые. Каркас содержит основной цикл

обработки и зачаточные средства обработки ошибок:

int main_loop(filter* p)

{

for (;;) {

try {

p->start();

while (p->read()) {

p->compute();

p->write();

}

return p->result();

}

catch (filter::Retry& m) {

cout << m.message() << '\n';

int i = p->retry();

if (i) return i;

}

catch (...) {

cout << "Fatal filter error\n";

return 1;

}

}

}

Теперь прикладную программу можно написать так:

class myfilter : public filter {

istream& is;

ostream& os;

char c;

int nchar;

public:

int read() { is.get(c); return is.good(); }

void compute() { nchar++; };

int result()

{ os << nchar

<< "characters read\n";

return 0;

}

myfilter(istream& ii, ostream& oo)

: is(ii), os(oo), nchar(0) { }

};

и вызывать ее следующим образом:

int main()

{

myfilter f(cin,cout);

return main_loop(&f);

}

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

должен создавать более развитые структуры и предоставлять больше

полезных функций, чем в нашем простом примере. Как правило, каркас

образует дерево узловых классов. Прикладной программист поставляет

только классы, служащие листьями в этом многоуровневом дереве,

благодаря чему достигается общность между различными прикладными

программами и упрощается повторное использование полезных функций,

предоставляемых каркасом. Созданию каркаса могут способствовать

библиотеки, в которых определяются некоторые полезные классы, например,

такие как scrollbar ($$12.2.5) и dialog_box ($$13.4). После определения

своих прикладных классов программист может использовать эти классы.

13.8 Интерфейсные классы

Про один из самых важных видов классов обычно забывают - это "скромные"

интерфейсные классы. Такой класс не выполняет какой-то большой

работы, ведь иначе, его не называли бы интерфейсным. Задача

интерфейсном класса приспособить некоторую полезную функцию к

определенному контексту. Достоинство интерфейсных классов в том,

что они позволяют совместно использовать полезную функцию, не загоняя

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

сможет сама по себе одинаково хорошо удовлетворить самые разные запросы.

Интерфейсный класс в чистом виде даже не требует генерации кода.

Вспомним описание шаблона типа Splist из $$8.3.2:

template<class T>

class Splist : private Slist<void*> {

public:

void insert(T* p) { Slist<void*>::insert(p); }

void append(T* p) { Slist<void*>::append(p); }

T* get() { return (T*) Slist<void*>::get(); }

};

Класс Splist преобразует список ненадежных обобщенных указателей

типа void* в более удобное семейство надежных классов, представляющих

списки. Чтобы применение интерфейсных классов не было слишком накладно,

нужно использовать функции-подстановки. В примерах, подобных

приведенному, где задача функций-подстановок только подогнать

тип, накладные расходы в памяти и скорости выполнения программы

не возникают.

Естественно, можно считать интерфейсным абстрактный

базовый класс, который представляет абстрактный тип, реализуемый

конкретными типами ($$13.3), также как и управляющие классы

из раздела 13.9. Но здесь мы рассматриваем классы, у которых нет

иных назначений - только задача адаптации интерфейса.

Рассмотрим задачу слияния двух иерархий классов с помощью

множественного наследования. Как быть в случае коллизии

имен, т.е. ситуации, когда в двух классах используются виртуальные

функции с одним именем, производящие совершенно разные операции?

Пусть есть видеоигра под названием "Дикий запад", в которой диалог

с пользователем организуется с помощью окна общего вида (класс

Window):

class Window {

// ...

virtual void draw();

};

class Cowboy {

// ...

virtual void draw();

};

class CowboyWindow : public Cowboy, public Window {

// ...

};

В этой игре класс CowboyWindow представляет движение ковбоя на экране

и управляет взаимодействием игрока с ковбоем. Очевидно, появится

много полезных функций, определенных в классе Window и

Cowboy, поэтому предпочтительнее использовать множественное наследование,

чем описывать Window или Cowboy как члены. Хотелось бы передавать

этим функциям в качестве параметра объект типа CowboyWindow, не требуя

от программиста указания каких-то спецификаций объекта. Здесь

как раз и возникает вопрос, какую функции выбрать для CowboyWindow:

Cowboy::draw() или Window::draw().

В классе CowboyWindow может быть только одна функция с именем

draw(), но поскольку полезная функция работает с объектами Cowboy

или Window и ничего не знает о CowboyWindow, в классе CowboyWindow

должны подавляться (переопределяться) и функция Cowboy::draw(), и

функция Window_draw(). Подавлять обе функции с помощью одной -

draw() неправильно, поскольку, хотя используется одно имя, все же

все функции draw() различны и не могут переопределяться одной.

Наконец, желательно, чтобы в классе CowboyWindow наследуемые

функции Cowboy::draw() и Window::draw() имели различные однозначно

заданные имена.

Для решения этой задачи нужно ввести дополнительные классы для

Cowboy и Window. Вводится два новых имени

для функций draw() и гарантируется, что их вызов

в классах Cowboy и Window приведет к вызову функций с новыми именами:

class CCowboy : public Cowboy {

virtual int cow_draw(int) = 0;

void draw() { cow_draw(i); } // переопределение Cowboy::draw

};

class WWindow : public Window {

virtual int win_draw() = 0;

void draw() { win_draw(); } // переопределение Window::draw

};

Теперь с помощью интерфейсных классов CCowboy и WWindow можно

определить класс CowboyWindow и сделать требуемые переопределения

функций cow_draw() и win_draw:

class CowboyWindow : public CCowboy, public WWindow {

// ...

void cow_draw();

void win_draw();

};

Отметим, что в действительности трудность возникла лишь потому, что

у обеих функций draw() одинаковый тип параметров. Если бы типы

параметров различались, то обычные правила разрешения неоднозначности

при перегрузке гарантировали бы, что трудностей не возникнет, несмотря на

наличие различных функций с одним именем.

Для каждого случая использования интерфейсного класса можно

предложить такое расширение языка, чтобы требуемая адаптация

проходила более эффективно или задавалась более элегантным способом.

Но такие случаи являются достаточно редкими, и нет смысла чрезмерно

перегружать язык, предоставляя специальные средства для каждого

отдельного случая. В частности, случай коллизии имен при слиянии иерархий

классов довольно редки, особенно если сравнивать с

тем, насколько часто программист создает классы. Такие случаи

могут возникать при слиянии иерархий классов из разных

областей (как в нашем примере: игры и операционные системы).

Слияние таких разнородных структур классов всегда непростая задача,

и разрешение коллизии имен является в ней далеко не самой трудной

частью. Здесь возникают проблемы из-за разных стратегий обработки

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

с коллизией имен, был приведен потому, что предложенное решение:

введение интерфейсных классов с функциями-переходниками, - имеет

много других применений. Например, с их помощью можно менять

не только имена, но и типы параметров и возвращаемых значений,

вставлять определенные динамические проверки и т.д.

Функции-переходники CCowboy::draw() и WWindow_draw являются

виртуальными, и простая оптимизация с помощью подстановки невозможна.

Однако, есть возможность, что транслятор распознает такие функции

и удалит их из цепочки вызовов.

Интерфейсные функции служат для приспособления интерфейса к

запросам пользователя. Благодаря им в интерфейсе собираются операции,

разбросанные по всей программе. Обратимся к классу vector из $$1.4.

Для таких векторов, как и для массивов, индекс

отсчитывается от нуля. Если пользователь хочет работать с

диапазоном индексов, отличным от диапазона 0..size-1, нужно сделать

соответствующие приспособления, например, такие:

void f()

{

vector v(10); // диапазон [0:9]

// как будто v в диапазоне [1:10]:

for (int i = 1; i<=10; i++) {

v[i-1] = ... // не забыть пересчитать индекс

}

// ...

}

Лучшее решение дает класс vec c произвольными границами индекса:

class vec : public vector {

int lb;

public:

vec(int low, int high)

: vector(high-low+1) { lb=low; }

int& operator[](int i)

{ return vector::operator[](i-lb); }

int low() { return lb; }

int high() { return lb+size() - 1; }

};

Класс vec можно использовать без дополнительных операций, необходимых

в первом примере:

void g()

{

vec v(1,10); // диапазон [1:10]

for (int i = 1; i<=10; i++) {

v[i] = ...

}

// ...

}

Очевидно, вариант с классом vec нагляднее и безопаснее.

Интерфейсные классы имеют и другие важные области применения,

например, интерфейс между программами на С++ и программами на другом

языке ($$12.1.4) или интерфейс с особыми библиотеками С++.

13.9 Управляющие классы

Концепция абстрактного класса дает эффективное средство для разделения

интерфейса и его реализации. Мы применяли эту концепцию и получали