Бьерн Страуструп. Язык программирования С Второе дополненное издание
 Скачать 2.87 Mb.
|
|
13.5.4 Расширенная динамическая информация о типе В классе Type_info содержится только минимум информации, необходимой для идентификации типа и безопасных операций приведения. Но поскольку в самом классе Type_info есть функции-члены info() и get_info(), можно построить производные от него классы, чтобы в динамике определять, какие объекты Type_info возвращают эти функции. Таким образом, не меняя класса Type_info, пользователь может получать больше информации о типе с помощью объектов, возвращаемых функциями dynamic_type() и static_type(). Во многих случаях дополнительная информация должна содержать таблицу членов объекта: struct Member_info { char* name; Type_info* tp; int offset; }; class Map_info : public Type_info { Member_info** mi; public: static const Type_info info_obj; virtual typeid get_info() const; static typeid info(); // функции доступа }; Класс Type_info вполне подходит для стандартной библиотеки. Это базовый класс с минимумом необходимой информации, из которого можно получать производные классы, предоставляющие больше информации. Эти производные классы могут определять или сами пользователи, или какие-то служебные программы, работающие с текстом на С++, или сами трансляторы языка. 13.5.5 Правильное и неправильное использование динамической информации о типе Динамическая информация о типе может использоваться во многих ситуациях, в том числе для: объектного ввода-вывода, объектно-ориентированных баз данных, отладки. В тоже время велика вероятность ошибочного использования такой информации. Известно,что в языке Симула использование таких средств, как правило, приводит к ошибкам. Поэтому эти средства не были включены в С++. Слишком велик соблазн воспользоваться динамической информацией о типе, тогда как правильнее вызвать виртуальную функцию. Рассмотрим в качестве примера класс Shape из $$1.2.5. Функцию rotate можно было задать так: void rotate(const Shape& s) // неправильное использование динамической // информации о типе { if (ref_type_info(s)==static_type_info(Circle)) { / / для этой фигуры ничего не надо } else if (ref_type_info(s)==static_type_info(Triangle)) { // вращение треугольника } else if (ref_type_info(s)==static_type_info(Square)) { // вращение квадрата } // } Если для переключателя по типу поля мы используем динамическую информацию о типе, то тем самым нарушаем в программе принцип модульности и отрицаем сами цели объектно-ориентированного программирования. К тому же это решение чревато ошибками: если в качестве параметра функции будет передан объект производного от Circle класса, то она сработает неверно (действительно, Бьерн Страуструп. Язык программирования С++ 351 вращать круг (Circle) нет смысла, но для объекта, представляющего производный класс, это может потребоваться). Опыт показывает, что программистам, воспитанным на таких языках как С или Паскаль, трудно избежать этой ловушки. Стиль программирования этих языков требует меньше предусмотрительности, а при создании библиотеки такой стиль можно просто считать небрежностью. Может возникнуть вопрос, почему в интерфейс с системой динамической информации о типе включена условная операция приведения ptr_cast(), а не операция is_base(), которая непосредственно определяется с помощью операции has_base() из класса Type_info. Рассмотрим такой пример: void f(dialog_box& db) { if (is_base(&db,dbox_w_str)) { // является ли db базовым // для dbox_w-str? dbox_w_str* dbws = (dbox_w_str*) &db; // } // } Решение с помощью ptr_cast ($$13.5) более короткое, к тому же здесь явная и безусловная операция приведения отделена от проверки в операторе if, значит появляется возможность ошибки, неэффективности и даже неверного результата. Неверный результат может возникнуть в тех редких случаях, когда система динамической идентификации типа распознает, что один тип является производным от другого, но транслятору этот факт неизвестен, например: class D; class B; void g(B* pb) { if (is_base(pb,D)) { D* pb = (D*)pb; // } // } Если транслятору пока неизвестно следующее описание класса D: class D : public A, public B { // }; то возникает ошибка, т.к. правильное приведение указателя pb к D* требует изменения значения указателя. Решение с операцией ptr_cast() не сталкивается с этой трудностью, поскольку эта операция применима только при условии, что в области видимости находятся описания обеих ее параметров. Приведенный пример показывает, что операция приведения для неописанных классов по сути своей ненадежна, но запрещение ее существенно ухудшает совместимость с языком С. 13.6 Обширный интерфейс Когда обсуждались абстрактные типы ($$13.3) и узловые классы ($$13.4), было подчеркнуто, что все функции базового класса реализуются в самом базовом или в производном классе. Но существует и другой способ построения классов. Рассмотрим, например, списки, массивы, ассоциативные массивы, деревья и т.д. Естественно желание для всех этих типов, часто называемых контейнерами, создать обобщающий их класс, который можно использовать в качестве интерфейса с любым из перечисленных типов. Очевидно, что пользователь не должен знать детали, касающиеся конкретного контейнера. Но задача определения интерфейса для обобщенного контейнера нетривиальна. Предположим, что такой контейнер будет определен как абстрактный тип, тогда какие операции он должен предоставлять? Можно предоставить только те операции, которые есть в каждом контейнере, т.е. пересечение множеств операций, но такой интерфейс будет слишком узким. На самом деле, во многих, имеющих Бьерн Страуструп. Язык программирования С++ 352 смысл случаях такое пересечение пусто. В качестве альтернативного решения можно предоставить объединение всех множеств операций и предусмотреть динамическую ошибку, когда в этом интерфейсе к объекту применяется "несуществующая" операция. Объединение интерфейсов классов, представляющих множество понятий, называется обширным интерфейсом. Опишем "общий" контейнер объектов типа T: class container { public: struct Bad_operation { // класс особых ситуаций const char* p; Bad_operation(const char* pp) : p(pp) { } }; virtual void put(const T*) { throw Bad_operation("container::put"); } virtual T* get() { throw Bad_operation("container::get"); } virtual T*& operator[](int) { throw Bad_operation("container::[](int)"); } virtual T*& operator[](const char*) { throw Bad_operation("container::[](char*)"); } // }; Все-таки существует мало реализаций, где удачно представлены как индексирование, так и операции типа списочных, и, возможно, не стоит совмещать их в одном классе. Отметим такое различие: для гарантии проверки на этапе трансляции в абстрактном типе используются чистые виртуальные функции, а для обнаружения ошибок на этапе выполнения используются функции обширного интерфейса, запускающие особые ситуации. Можно следующим образом описать контейнер, реализованный как простой список с односторонней связью: class slist_container : public container, private slist { public: void put(const T*); T* get(); T*& operator[](int) { throw Bad_operation("slist::[](int)"); } T*& operator[](const* char) { throw Bad_operation("slist::[](char*)"); } // }; Чтобы упростить обработку динамических ошибок для списка введены операции индексирования. Можно было не вводить эти нереализованные для списка операции и ограничиться менее полной информацией, которую предоставляют особые ситуации, запущенные в классе container: class vector_container : public container, private vector { public: T*& operator[](int); T*& operator[](const char*); // }; Если быть осторожным, то все работает нормально: void f() { slist_container sc; vector_container vc; // } Бьерн Страуструп. Язык программирования С++ 353 void user(container& c1, container& c2) { T* p1 = c1.get(); T* p2 = c2[3]; // нельзя использовать c2.get() или c1[3] // } Все же для избежания ошибок при выполнении программы часто приходится использовать динамическую информацию о типе ($$13.5) или особые ситуации ($$9). Приведем пример: void user2(container& c1, container& c2) /* обнаружение ошибки просто, восстановление - трудная задача */ { try { T* p1 = c1.get(); T* p2 = c2[3]; // } catch(container::Bad_operation& bad) { // Приехали! // А что теперь делать? } } или другой пример: void user3(container& c1, container& c2) /* обнаружение ошибки непросто, а восстановление по прежнему трудная задача */ { slist* sl = ptr_cast(slist_container,&c1); vector* v = ptr_cast(vector_container, &c2); if (sl && v) { T* p1 = c1.get(); T* p2 = c2[3]; // } else { // Приехали! // А что теперь делать? } } Оба способа обнаружения ошибки, показанные на этих примерах, приводят к программе с "раздутым" кодом и низкой скоростью выполнения. Поэтому обычно просто игнорируют возможные ошибки в надежде, что пользователь на них не натолкнется. Но задача от этого не упрощается, ведь полное тестирование затруднительно и требует многих усилий. Поэтому, если целью является программа с хорошими характеристиками, или требуются высокие гарантии корректности программы, или, вообще, есть хорошая альтернатива, лучше не использовать обширные интерфейсы. Кроме того, использование обширного интерфейса нарушает взаимнооднозначное соответствие между классами и понятиями, и тогда начинают вводить новые производные классы просто для удобства реализации. Бьерн Страуструп. Язык программирования С++ 354 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; } } } Теперь прикладную программу можно написать так: Бьерн Страуструп. Язык программирования С++ 355 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 T* get() { return (T*) Slist }; Класс Splist преобразует список ненадежных обобщенных указателей типа void* в более удобное семейство надежных классов, представляющих списки. Чтобы применение интерфейсных классов не было слишком накладно, нужно использовать функции-подстановки. В примерах, подобных приведенному, где задача функций-подстановок только подогнать тип, накладные расходы в памяти и скорости выполнения программы не возникают. Естественно, можно считать интерфейсным абстрактный базовый класс, который представляет Бьерн Страуструп. Язык программирования С++ 356 абстрактный тип, реализуемый конкретными типами ($$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(); }; Бьерн Страуструп. Язык программирования С++ 357 Отметим, что в действительности трудность возникла лишь потому, что у обеих функций 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] = } // } Бьерн Страуструп. Язык программирования С++ 358 Очевидно, вариант с классом vec нагляднее и безопаснее. Интерфейсные классы имеют и другие важные области применения, например, интерфейс между программами на С++ и программами на другом языке ($$12.1.4) или интерфейс с особыми библиотеками С++. |