С++? Простое решение -
определить функцию, проверяющую инвариант, и вставить вызовы этой
функции в общие операции. Например:

     class String {
         int sz;
         int* p;
     public:
         class Range {};
         class Invariant {};

         void check();

         String(const char* q);
         ~String();
         char& operator[](int i);
         int size() { return sz; }
         //...
     };

     void String::check()
     {
         if (p==0 || sz<0 || TOO_LARGE<=sz || p[sz-1])
            throw Invariant;
     }

     char& String::operator[](int i)
     {
         check();                        // проверка на входе
         if (i<0 || i<sz) throw Range;   // действует
         check();                        // проверка на выходе
         return v[i];
     }

Этот вариант прекрасно работает и не осложняет жизнь программиста.
Но для такого простого класса как String проверка инварианта будет
занимать большую часть времени счета. Поэтому программисты обычно
выполняют проверку инварианта только при отладке:

     inline void String::check()
     {
         if (!NDEBUG)
             if (p==0 || sz<0 || TOO_LARGE<=sz || p[sz])
                 throw Invariant;
     }

Мы выбрали имя NDEBUG, поскольку это макроопределение, которое
используется для аналогичных целей в стандартном макроопределении
С assert(). Традиционно NDEBUG устанавливается с целью указать,
что отладки нет. Указав, что check() является подстановкой, мы
гарантировали, что никакая программа не будет создана, пока константа
NDEBUG не будет установлена в значение, обозначающее отладку.
С помощью шаблона типа Assert() можно задать менее регулярные
утверждения, например:

     template<class T, class X> inline void Assert(T expr,X x)
     {
         if (!NDEBUG)
             if (!expr) throw x;
     }

вызовет особую ситуацию x, если expr ложно, и мы не отключили
проверку с помощью NDEBUG. Использовать Assert() можно так:

     class Bad_f_arg { };

     void f(String& s, int i)
     {
         Assert(0<=i && i<s.size(),Bad_f_arg());
         //...
     }

Шаблон типа Assert() подражает макрокоманде assert() языка С.
Если i не находится в требуемом диапазоне, возникает особая
ситуация Bad_f_arg.
    С помощью отдельной константы или константы из класса проверить
подобные утверждения или инварианты - пустяковое дело. Если же
необходимо проверить инварианты с помощью объекта, можно определить
производный класс, в котором проверяются операциями из класса, где нет
проверки, см. упр.8 в $$13.11.
   Для классов с более сложными операциями расходы на проверки могут
быть значительны, поэтому проверки можно оставить только для "поимки"
трудно обнаруживаемых ошибок. Обычно полезно оставлять по крайней
мере несколько проверок даже в очень хорошо отлаженной программе.
При всех условиях сам факт определения инвариантов и использования
их при отладке дает неоценимую помощь для получения правильной
программы и, что более важно, делает понятия, представленные
классами, более регулярными и строго определенными. Дело в том, что
когда вы создаете инварианты, то рассматриваете класс с другой
точки зрения и вносите определенную избыточность в программу.
То и другое увеличивает вероятность обнаружения ошибок, противоречий
и недосмотров.
Мы указали в $$11.3.3.5, что две самые общие формы преобразования
иерархии классов состоят в разбиении класса на два и в выделении
общей части двух классов в базовый класс. В обоих случаях хорошо
продуманный инвариант может подсказать возможность такого
преобразования. Если, сравнивая инвариант с программами операций,
можно обнаружить, что большинство проверок инварианта излишни,
то значит класс созрел для разбиения. В этом случае подмножество операций
имеет доступ только к подмножеству состояний объекта. Обратно,
классы созрели для слияния, если у них сходные инварианты, даже
при некотором различии в их реализации.

        12.2.7.2 Инкапсуляция

Отметим, что в С++ класс, а не отдельный объект, является той
единицей, которая должна быть инкапсулирована (заключена в оболочку).
Например:

     class list {
         list* next;
     public:
         int on(list*);
     };

     int list::on(list* p)
     {
         list* q = this;
         for(;;) {
             if (p == q) return 1;
             if (q == 0) return 0;
             q = q->next;
         }
     }

Здесь обращение к частному указателю list::next допустимо, поскольку
list::on() имеет доступ ко всякому объекту класса list, на который
у него есть ссылка. Если это неудобно, ситуацию можно упростить,
отказавшись от возможности доступа через функцию-член к
представлениям других объектов, например:

     int list::on(list* p)
     {
         if (p == this) return  1;
         if (p == 0) return 0;
         return next->on(p);
     }

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

        12.2.8 Программируемые отношения

Конкретный язык программирования не может прямо поддерживать
любое понятие любого метода проектирования. Если язык программирования
не способен прямо представить понятие проектирования, следует
установить удобное отображение конструкций, используемых в проекте,
на языковые конструкции. Например, метод проектирования может
использовать понятие делегирования, означающее, что всякая
операция, которая не определена для класса A, должна выполняться
в нем с помощью указателя p на соответствующий член класса B,
в котором она определена. На С++ нельзя выразить это прямо. Однако,
реализация этого понятия настолько в духе С++, что легко представить
программу реализации:

     class A {
         B* p;
         //...
         void f();
         void ff();
     };

     class B {
         //...
         void f();
         void g();
         void h();
      };

Тот факт, что В делегирует A с помощью указателя A::p,
выражается в следующей записи:

     class A {
         B* p;      // делегирование с помощью p
         //...
         void f();
         void ff();
         void g() { p->g(); }  // делегирование q()
         void h() { p->h(); }  // делегирование h()
      };

Для программиста совершенно очевидно, что здесь происходит, однако здесь
явно нарушается принцип взаимнооднозначного соответствия. Такие
"программируемые" отношения трудно выразить на языках программирования,
и поэтому к ним трудно применять различные вспомогательные средства.
Например, такое средство может не отличить "делегирование" от B
к A с помощью A::p от любого другого использования B*.
    Все-таки следует всюду, где это возможно, добиваться
взаимнооднозначного соответствия между понятиями проекта и понятиями
языка программирования. Оно дает определенную простоту и гарантирует,
что проект адекватно отображается в программе, что упрощает
работу программиста и вспомогательных средств.
Операции преобразований типа являются механизмом, с помощью которого
можно представить в языке класс программируемых отношений, а именно:
операция преобразования X::operator Y() гарантирует, что всюду,
где допустимо использование Y, можно применять и X. Такое же
отношение задает конструктор Y::Y(X). Отметим, что операция
преобразования типа (как и конструктор) скорее создает новый объект,
чем изменяет тип существующего объекта. Задать операцию преобразования
к функции Y - означает просто потребовать неявного применения
функции, возвращающей Y. Поскольку неявные применения операций
преобразования типа и операций, определяемых конструкторами, могут
привести к неприятностям, полезно проанализировать их в отдельности
еще в проекте.
  Важно убедиться, что граф применений операций преобразования типа
не содержит циклов. Если они есть, возникает двусмысленная ситуация,
при которой типы, участвующие в циклах, становятся несовместимыми в
комбинации. Например:

     class Big_int {
         //...
         friend Big_int operator+(Big_int,Big_int);
         //...
         operator Rational();
         //...
     };

     class Rational {
         //...
         friend Rational operator+(Rational,Rational);
         //...
         operator Big_int();
     };

Типы Rational и Big_int не так гладко взаимодействуют, как можно
было бы подумать:

     void f(Rational r, Big_int i)
     {
         //...
         g(r+i);   // ошибка, неоднозначность:
                   //        operator+(r,Rational(i)) или
                   //        operator+(Big_int(r),i)
         g(r,Rational(i));  // явное разрешение неопределенности
         g(Big_int(r),i);   // еще одно
     }

Можно было бы избежать таких "взаимных" преобразований, сделав
некоторые из них явными. Например, преобразование Big_int к типу
Rational можно было бы задать явно с помощью функции make_Rational()
вместо операции преобразования, тогда сложение в приведенном
примере разрешалось бы как g(BIg_int(r),i). Если нельзя избежать
"взаимных" операций преобразования типов, то нужно преодолевать
возникающие столкновения или с помощью явных преобразований (как было
показано), или с помощью определения нескольких различных версий
бинарной операции (в нашем случае +).

        12.3 Компоненты

В языке С++ нет конструкций, которые могут выразить прямо в программе
понятие компонента, т.е. множества связанных классов. Основная
причина этого в том, что множество классов (возможно с соответствующими
глобальными функциями и т.п.) может соединяться в компонент по
самым разным признакам. Отсутствие явного представления понятия в
языке затрудняет проведение границы между информацией (имена),
используемой внутри компонента, и информацией (имена), передаваемой
из компонента пользователям.
В идеале, компонент определяется множеством интерфейсов, используемых
для его реализации, плюс множеством интерфейсов, представляемых
пользователем, а все прочее считается "спецификой реализации" и
должно быть скрыто от остальных частей системы. Таково может быть
в действительности представление о компоненте у разработчика.
Программист должен смириться с тем фактом, что С++ не дает
общего понятия пространства имен компонента, так что его
приходится "моделировать" с помощью понятий классов и единиц
трансляции, т.е. тех средств, которые есть в С++ для ограничения
области действия нелокальных имен.
      Рассмотрим два класса, которые должны совместно использовать
функцию f() и переменную v. Проще всего описать f и v как
глобальные имена. Однако, всякий опытный программист знает, что
такое "засорение" пространства имен может привести в конце концов
к неприятностям: кто-то может ненарочно использовать имена f или v
не по назначению или нарочно обратиться  к f или v,
прямо используя "специфику реализации" и обойдя тем самым явный
интерфейс компонента. Здесь возможны три решения:
  [1] Дать "необычные" имена объектам и функциям, которые не
      рассчитаны на пользователя.
  [2] Объекты или функции, не предназначенные для пользователя,
      описать в одном из файлов программы как статические (static).
  [3] Поместить объекты и функции, не предназначенные для пользователя,
      в класс, определение которого закрыто для пользователей.
Первое решение примитивно и достаточно неудобно для создателя
программы, но оно действует:

     // не используйте специфику реализации compX,
     // если только вы не разработчик compX:
     extern void compX_f(T2*, const char*);
     extern T3 compX_v;
     // ...

Такие имена как compX_f и compX_v вряд ли могут привести к коллизии, а на
тот довод, что пользователь может быть злоумышленником и использовать
эти имена прямо, можно ответить, что пользователь в любом случае может
оказаться злоумышленником, и что языковые механизмы защиты предохраняют
от несчастного случая, а не от злого умысла. Преимущество этого
решения в том, что оно применимо всегда и хорошо известно. В то же
время оно некрасиво, ненадежно и усложняет ввод текста.
   Второе решение более надежно, но менее универсально:

     // специфика реализации compX:
     static void compX_f(T2* a1, const char *a2) { /* ... */ }
     static T3 compX_v;
     // ...

Трудно гарантировать, что информация, используемая в классах одного
компонента, будет доступна только в одной единице трансляции,
поскольку операции, работающие с этой информацией, должны
быть доступны везде. Это решение может к тому же привести к
громадным единицам трансляции, а в некоторых отладчиках для С++
не организован доступ к именам статических функций и переменных.
В то же время это решение надежно и часто оптимально для небольших
компонентов.
Третье решение можно рассматривать как формализацию и обобщение
первых двух:

      class compX_details {  // специфика реализации compX
      public:
         static void f(T2*, const char*);
         static T3 v;
         // ...
     };

Описание compX_details будет использовать только создатель класса,
остальные не должны включать его в свои программы.
    В компоненте конечно может быть много классов, не предназначенных
для общего пользования. Если их имена тоже рассчитаны только на
локальное использование, то их также можно "спрятать" внутри
классов, содержащих специфику реализации:

     class compX_details { // специфика реализации compX.
     public:
        // ...
        class widget {
           // ...
       };
       // ...
     };

Укажем, что вложенность создает барьер для использования widget
в других частях программы. Обычно классы, представляющие
ясные понятия, считаются первыми кандидатами на повторное
использование, и, значит составляют часть интерфейса компонента,
а не деталь реализации. Другими словами, хотя для сохранения
надлежащего уровня абстракции вложенные объекты, используемые для
представления некоторого объекта класса, лучше считать скрытыми
деталями реализации, классы, определяющие такие вложенные объекты,
лучше не делать скрытыми, если они имеют достаточную общность.
Так, в следующем примере упрятывание, пожалуй, излишне:

     class Car {
        class Wheel {
          // ...
        };
        Wheel flw, frw, rlw, rrw;
        // ...
     };

Во многих ситуациях для поддержания уровня абстракции понятия
машины (Car) следует упрятывать реальные колеса (класс Wheel),
ведь когда вы работаете с машиной, вы не можете независимо от нее
использовать колеса. С другой стороны, сам класс Wheel является
вполне подходящим для широкого использования, поэтому лучше
вынести его определение из класса Car:

      class Wheel {
        // ...
      };
      class Car {
         Wheel flw, frw, rlw, rrw;
         // ...
      };

Использовать ли вложенность? Ответ на этот вопрос зависит
от целей проекта и общности используемых понятий. Как вложенность,
так и ее отсутствие могут быть вполне допустимыми решениями для данного
проекта. Но поскольку вложенность предохраняет от засорения
общего пространства имен, в своде правил ниже рекомендуется
использовать вложенность, если только нет причин не делать этого.
     Отметим, что заголовочные файлы дают мощное средство для
различных представлений компонент разным пользователям, и они же
позволяют удалять из представления компонента для пользователя те
классы, которые связаны со спецификой реализации.
    Другим средством построения компонента и представления его
пользователю служит иерархия. Тогда базовый класс используется как
хранилище общих данных и функций. Таким способом устраняется
проблема, связанная с глобальными данными и функциями, предназначенными
для реализации общих запросов классов данного компонента.
С другой стороны, при таком решении классы компонента становятся
слишком связанными друг с другом, а пользователь попадает в зависимость
от всех базовых классов тех компонентов, которые ему действительно
нужны. Здесь также проявляется тенденция к тому, что члены,
представляющие "полезные" функции и данные "всплывают"  к базовому
классу, так что при слишком большой иерархии классов проблемы с
глобальными данными и функциями проявятся уже в рамках этой иерархии.
Вероятнее всего, это произойдет для иерархии с одним корнем, а для
борьбы с этим явлением можно применять виртуальные базовые классы
($$6.5.4). Иногда лучше выбрать иерархию для представления компонента,
а иногда нет. Как всегда сделать выбор предстоит разработчику.

        12.4 Интерфейсы и реализации

Идеальный интерфейс должен
   - представлять полное и согласованное множество понятий для
     пользователя,
   - быть согласованным для всех частей компонента,
   - скрывать специфику реализации от пользователя,
   - допускать несколько реализаций,
   - иметь статическую систему типов,
   - определяться с помощью типов из области приложения,
   - зависеть от других интерфейсов лишь частично и вполне определенным
     образом.
Отметив необходимость согласованности для всех классов, которые
образуют интерфейс компонента с остальным миром, мы можем упростить
вопрос интерфейса, рассмотрев только один класс, например:

    class X {  // пример плохого определения интерфейса
      Y a;
      Z b;
    public:
      void f(const char* ...);
      void g(int[],int);
      void set_a(Y&);
      Y& get_a();
    };

В этом интерфейсе содержится ряд потенциальных проблем:
   -Типы Y и Z  используются так, что определения Y и Z должны быть
    известны во время трансляции.
   - У функции X::f может быть произвольное число параметров
     неизвестного типа (возможно, они каким-то образом контролируются
     "строкой формата", которая передается в качестве первого
     параметра).
   - Функция X::g имеет параметр типа int[]. Возможно это нормально,
     но обычно это свидетельствует о том, что определение слишком
     низкого уровня абстракции. Массив целых не является достаточным
     определением, так как неизвестно из скольких он может
     состоять элементов.
   - Функции set_a() и get_a(), по всей видимости, раскрывают
     представление объектов класса X, разрешая прямой доступ
     к X::a.
   Здесь функции-члены образуют интерфейс на слишком низком уровне
абстракции. Как правило классы с интерфейсом такого уровня относятся
к специфике реализации большого компонента, если они вообще могут
к чему-нибудь относиться. В идеале параметр функции из интерфейса
должен сопровождаться такой информацией, которой достаточно
для его понимания. Можно сформулировать такое правило: надо уметь
передавать запросы на обслуживание удаленному серверу по узкому
каналу.
    Язык С++ раскрывает представление класса как часть интерфейса.
Это представление может быть скрытым (с помощью private или
protected), но обязательно доступным транслятору, чтобы он мог разместить
автоматические (локальные) переменные, сделать подстановку тела
функции и т.д. Отрицательным следствием этого является то, что
использование типов классов в представлении класса может привести к
возникновению нежелательных зависимостей. Приведет ли использование
членов типа Y и Z к проблемам, зависит от того, каковы в действительности
типы Y и Z. Если это достаточно простые типы, наподобие complex или
String, то их использование будет вполне допустимым в большинстве случаев.
Такие типы можно считать устойчивыми, и необходимость включать
определения их классов будет вполне допустимой нагрузкой для транслятора.
Если же Y и Z сами являются классами интерфейса большого
компонента (например, типа графической системы или системы обеспечения
банковских счетов), то прямую зависимость от них можно считать
неразумной. В таких случаях  предпочтительнее использовать член,
являющийся указателем или ссылкой:

      class X {
        Y* a;
        Z& b;
        // ...
      };

При этом способе определение X отделяется от определений Y и Z, т.е.
теперь определение X зависит только от имен Y и Z. Реализация X,
конечно, будет по-прежнему зависеть от определений Y и Z, но это
уже не будет оказывать неблагоприятного влияния на пользователей X.
    Вышесказанное иллюстрирует важное утверждение: У интерфейса,
скрывающего значительный объем информации (что и должен делать полезный
интерфейс), должно быть существенно меньше зависимостей, чем
у реализации, которая их скрывает. Например, определение класса X
можно транслировать без доступа к определениям Y и Z. Однако,
в определениях функций-членов класса X, которые работают со
ссылками на объекты Y и Z, доступ к определениям Y и Z необходим.
При анализе зависимостей следует рассматривать раздельно
зависимости в интерфейсе и в реализации. В идеале для обоих видов
зависимостей граф зависимостей системы должен быть направленным
нецикличным графом, что облегчает понимание и тестирование
системы. Однако, эта цель более важна и чаще достижима для
реализаций, чем для интерфейсов.
    Отметим, что класс определяет три интерфейса:

    class X {
    private:
      // доступно только для членов и друзей
    protected:
      // доступно только для членов и друзей, а также
      // для членов и друзей производных классов
    public:
      // общедоступно
    };

Члены должны образовывать самый ограниченный из возможных интерфейсов.
Иными словами, член должен быть описан как private, если нет
причин для более широкого доступа к нему; если же таковые есть, то
член должен быть описан как protected, если нет дополнительных причин
задать его как public. В большинстве случаев плохо задавать все данные,
представляемые членами, как public. Функции и классы, образующие общий
интерфейс, должны быть спроектированы таким образом, чтобы представление
класса совпадало с его ролью в проекте как средства представления
понятий. Напомним, что друзья являются частью общего интерфейса.
    Отметим, что абстрактные классы можно использовать для
представления понятия упрятывания более высокого уровня ($$1.4.6,
$$6.3, $$13.3).

        12.5 Свод правил

В этой главе мы коснулись многих тем, но, как правило, избегали
давать настоятельные и конкретные рекомендации по рассматриваемым
вопросам. Это отвечает моему убеждению, что нет "единственно верного
решения". Принципы и приемы следует применять способом, наиболее
подходящим для конкретной задачи. Здесь требуются вкус, опыт и
разум. Тем не менее, можно предложить свод правил, которые
разработчик может использовать в качестве ориентиров, пока не
приобретет достаточно опыта, чтобы выработать лучшие.
Этот свод правил приводится ниже.
     Он может служить отправной точкой в процессе выработки
основных направлений проекта конкретной задачи, или же он может
использоваться организацией в качестве проверочного списка. Подчеркну
еще раз, что эти правила не являются универсальными и не могут
заменить собой размышления.
  - Нацеливайте пользователя на применение абстракции данных и
    объектно-ориентированного программирования.
    - Постепенно переходите на новые методы, не спешите.
    - Используйте возможности С++ и методы обЪектно-ориентированного
      программирования только по мере надобности.
    _ Добейтесь соответствия стиля проекта и программы.
  - Концентрируйте внимание на проектировании компонента.
  _ Используйте классы для представления понятий.
    - Используйте общее наследование для представления отношений "есть".
    - Используйте принадлежность для представления отношений "имеет".
    - Убедитесь, что отношения использования понятны, не образуют
      циклов, и что число их минимально.
    - Активно ищите общность среди понятий области приложения и
      реализации, и возникающие в результате более общие понятия
      представляйте как базовые классы.
  - Определяйте интерфейс так, чтобы открывать минимальное количество
    требуемой информации:
    - Используйте, всюду где это можно, частные данные и функции-члены.
    - Используйте описания public или protected, чтобы отличить
      запросы разработчика производных классов от запросов обычных
      пользователей.
    - Сведите к минимуму зависимости одного интерфейса от других.
    - Поддерживайте строгую типизацию интерфейсов.
    - Задавайте интерфейсы в терминах типов из области приложения.
Дополнительные правила можно найти $$11.5.




         * ПРОЕКТИРОВАНИЕ БИБЛИОТЕК

                      Проект библиотеки - это проект языка,
                            (фольклор фирмы Bell Laboratories)
                      ... и наоборот.
                           - А. Кениг

Эта глава содержит описание различных приемов, оказавшихся полезными
при создании библиотек для языка С++. В частности, в ней
рассматриваются конкретные типы, абстрактные типы, узловые классы,
управляющие классы и интерфейсные классы. Помимо этого обсуждаются
понятия обширного интерфейса и структуры области приложения,
использование динамической информации о типах и методы управления
памятью. Внимание акцентируется на том, какими свойствами должны
обладать библиотечные классы, а не на специфике языковых средств,
которые используются для реализации таких классов, и не на
определенных полезных функциях, которые должна предоставлять библиотека.

        13.1 Введение

Разработка библиотеки общего назначения - это гораздо более трудная
задача, чем создание обычной программы. Программа - это решение
конкретной задачи для конкретной области приложения, тогда как
библиотека должна предоставлять возможность решение для множества задач,
связанных с многими областями приложения. В обычной программе
позволительны сильные допущения об ее окружении, тогда как хорошую
библиотеку можно успешно использовать в разнообразных окружениях,
создаваемых множеством различных программ. Чем более общей и полезной
окажется библиотека, тем в большем числе окружений она будет
проверяться, и тем жестче будут требования к ее корректности, гибкости,
эффективности, расширяемости, переносимости, непротиворечивости,
простоте, полноте, легкости использования и т.д. Все же библиотека
не может дать вам все, поэтому нужен определенный компромисс.
Библиотеку можно рассматривать как специальный, интересный вариант
того, что в предыдущей главе мы называли компонентом. Каждый
совет по проектированию и сопровождению компонентов становится
предельно важным для библиотек, и, наоборот, многие методы
построения библиотек находят применение при проектировании различных
компонентов.
    Было бы слишком самонадеянно указывать как следует
конструировать библиотеки. В прошлом оказались успешными несколько
различных методов, а сам предмет остается полем активных дискуссий
и экспериментов. Здесь только обсуждаются некоторые важные аспекты
этой задачи и предлагаются некоторые приемы, оказавшиеся полезными
при создании библиотек. Не следует забывать, что библиотеки предназначены
для совершенно разных областей программирования, поэтому не приходится
рассчитывать, что какой-то один метод окажется наиболее приемлемым для
всех библиотек. Действительно, нет никаких причин полагать, что методы,
оказавшиеся полезными при реализации средств параллельного
программирования для ядра многопроцессорной операционной системы,
окажутся наиболее приемлемыми при создании библиотеки, предназначенной
для решения научных задач, или библиотеки, представляющей графический
интерфейс.
   Понятие класса С++ может использоваться самыми разными
способами, поэтому разнообразие стилей программирования может
привести к беспорядку. Хорошая библиотека для сведения такого
беспорядка к минимуму обеспечивает согласованный стиль программирования,
или, по крайней мере, несколько таких стилей. Этот подход делает
библиотеку более "предсказуемой", а значит позволяет легче и быстрее
изучить ее и правильно использовать. Далее описываются пять
"архитипичных" классов, и обсуждаются присущие им сильные и слабые
стороны: конкретные типы ($$13.2), абстрактные типы ($$13.3),
узловые классы ($$13.4), интерфейсные классы ($$13.8), управляющие
классы ($$13.9). Все эти виды классов относятся к области понятий,
а не являются конструкциями языка. Каждое понятие воплощается
с помощью основной конструкции - класса. В идеале надо иметь
минимальный набор простых и ортогональных видов классов, исходя из
которого можно построить любой полезный и разумно-определенный класс.
Идеал нами не достигнут и, возможно, недостижим вообще. Важно понять,
что любой из перечисленных видов классов играет свою роль при
проектировании библиотеки и, если рассчитывать на общее применение,
никакой из них не является по своей сути лучше других.
   В этой главе вводится понятие обширного интерфейса ($$13.6),
чтобы выделить некоторый общий случай всех этих видов классов.
С помощью него определяется понятие каркаса области приложения ($$13.7).
  Здесь рассматриваются прежде всего классы, относящиеся строго к
одному из перечисленных видов, хотя, конечно, используются
классы и гибридного вида. Но использование класса гибридного вида
должно быть результатом осознанного решения, возникшего при оценке
плюсов и минусов различных видов, а не результатом пагубного стремления
уклониться от выбора вида класса (слишком часто "отложим пока выбор"
означает просто нежелание думать). Неискушенным разработчикам
библиотеки лучше всего держаться подальше от классов гибридного
вида. Им можно посоветовать следовать стилю программирования той из
существующих библиотек, которая обладает возможностями, необходимыми для
проектируемой библиотеки. Отважиться на создание библиотеки общего
назначения может только искушенный программист, и каждый создатель
библиотеки впоследствии будет "осужден" на долгие годы использования,
документирования и сопровождения своего собственного создания.
   В языке С++ используются статические типы. Однако, иногда
возникает необходимость в дополнение к возможностям, непосредственно
предоставляемым виртуальными функциями, получать динамическую информацию
о типах. Как это сделать, описано в $$13.5. Наконец, перед всякой
нетривиальной библиотекой встает задача управления памятью. Приемы ее
решения рассматриваются в $$13.10. Естественно, в этой главе невозможно
рассмотреть все методы, оказавшиеся полезными при создании библиотеки.
Поэтому можно отослать к другим местам книги, где рассмотрены
следующие вопросы: работа с ошибками и устойчивость к ошибкам ($$9.8),
использование функциональных объектов  и обратных вызовов ($$10.4.2
и $$9.4.3) , использование шаблонов типа для построения классов
($$8.4).
   Многие темы этой главы связаны с классами, являющимися контейнерами,
(например, массивы и списки). Конечно, такие контейнерные классы
являются шаблонами типа (как было сказано в $$1.и 4.3 $$8). Но
здесь для упрощения изложения в примерах используются классы,
содержащие указатели на объекты типа класс. Чтобы получить настоящую
программу, надо использовать шаблоны типа, как показано в главе 8.

        13.2 Конкретные типы

Такие классы как vector ($$1.4), Slist ($$8.3), date ($$5.2.2) и
complex ($$7.3) являются конкретными в том смысле, что каждый из
них представляет довольно простое понятие и обладает необходимым
набором операций. Имеется взаимнооднозначное соответствие между
интерфейсом класса и его реализацией. Ни один из них  (изначально)
не предназначался в качестве базового для получения производных классов.
Обычно в иерархии классов конкретные типы стоят особняком. Каждый
конкретный тип можно понять изолированно, вне связи с другими классами.
Если реализация конкретного типа удачна, то работающие с ним программы
сравнимы по размеру и скорости со сделанными вручную программами,
в которых используется некоторая специальная версия общего понятия.
Далее, если произошло значительное изменение реализации, обычно
модифицируется и интерфейс, чтобы отразить эти изменения. Интерфейс,
по своей сути, обязан показать какие изменения оказались существенными
в данном контексте. Интерфейс более высокого уровня оставляет
больше свободы для изменения реализации, но может ухудшить
характеристики программы. Более того, хорошая реализация зависит
только от минимального числа действительно существенных классов.
Любой из этих классов можно использовать без накладных расходов,
возникающих на этапе трансляции или выполнения, и вызванных
приспособлением к другим, "сходным" классам программы.
   Подводя итог, можно указать такие условия, которым должен
удовлетворять конкретный тип:
   [1] полностью отражать данное понятие и метод его реализации;
   [2] с помощью подстановок и операций, полностью использующих
       полезные свойства понятия и его реализации, обеспечивать
       эффективность по скорости и памяти, сравнимую
       с "ручными программами";
   [3] иметь минимальную зависимость от других классов;
   [4] быть понятным и полезным даже изолированно.
Все это должно привести к тесной связи между пользователем и
программой, реализующей конкретный тип. Если в реализации произошли
изменения, программу пользователя придется перетранслировать,
поскольку в ней наверняка содержатся вызовы функций, реализуемые
подстановкой, а также локальные переменные конкретного типа.
   Для некоторых областей приложения конкретные типы обеспечивают
основные типы, прямо не представленные в С++, например:
комплексные числа, вектора, списки, матрицы, даты, ассоциативные
массивы, строки символов и символы, из другого (не английского)
алфавита. В мире, состоящем из конкретных понятий, на самом деле
нет такой вещи как список. Вместо этого есть множество списочных
классов, каждый из которых специализируется на представлении
какой-то версии понятия список. Существует дюжина списочных
классов, в том числе: список с односторонней связью; список с
двусторонней связью; список с односторонней связью, в котором
поле связи не принадлежит объекту; список с двусторонней связью,
в котором поля связи не принадлежат объекту; список с односторонней
связью, для которого можно просто и эффективно определить входит
ли в него данный объект; список с двусторонней связью, для
которого можно просто и эффективно определить входит ли в него данный
объект и т.д.
    Название "конкретный тип" (CDT - concrete data type, т.е.
конкретный тип данных) , было выбрано по контрасту с термином
"абстрактный тип" (ADT - abstract data type, т.е. абстрактный тип
данных). Отношения между CDT и ADT обсуждаются в $$13.3.
    Существенно, что конкретные типы не предназначены для явного
выражения некоторой общности. Так, типы slist и vector можно
использовать в качестве альтернативной реализации понятия
множества, но в языке это явно не отражается. Поэтому, если
программист хочет работать с множеством, использует конкретные
типы и не имеет определения класса множество, то он должен выбирать
между типами slist и vector. Тогда программа записывается в
терминах выбранного класса, скажем, slist, и если потом предпочтут
использовать другой класс, программу придется переписывать.
    Это потенциальное неудобство компенсируется наличием всех
"естественных" для данного класса операций, например таких, как
индексация для массива и удаление элемента для списка. Эти
операции представлены в оптимальном варианте, без "неестественных"
операций типа индексации списка или удаления массива, что могло
бы вызвать путаницу. Приведем пример:

         void my(slist& sl)
         {
           for (T* p = sl.first(); p; p = sl.next())
           {
              // мой код
           }
           // ...
         }

         void your(vector& v)
         {
           for (int i = 0; i<v.size(); i++)
           {
             // ваш код
           }
           // ...
         }

Существование таких "естественных" для выбранного метода реализации
операций обеспечивает эффективность программы и значительно облегчает
ее написание. К тому же, хотя реализация вызова подстановкой обычно
возможна только для простых операций типа индексации массива или
получения следующего элемента списка, она оказывает значительный
эффект на скорость выполнения программы. Загвоздка здесь состоит в том,
что фрагменты программы, использующие по своей сути эквивалентные операции,
как, например, два приведенных выше цикла, могут выглядеть непохожими
друг на друга, а фрагменты программы, в которых для эквивалентных
операций используются разные конкретные типы, не могу заменять друг
друга. Обычно, вообще, невозможно свести сходные фрагменты программы
в один.
     Пользователь, обращающийся к некоторой функции, должен точно
указать тип объекта, с которым работает функция, например:

        void user()
        {
          slist sl;
          vector v(100);

          my(sl);
          your(v);

          my(v);    // ошибка: несоответствие типа
          your(sl); // ошибка: несоответствие типа
        }

Чтобы компенсировать жесткость этого требования, разработчик некоторой
полезной функции должен предоставить несколько ее версий, чтобы у
пользователя был выбор:

        void my(slist&);
        void my(vector&);

        void your(slist&);
        void your(vector&);

        void user()
        {
          slist sl;
          vector v(100);

          my(sl);
          your(v);

          my(v);     // теперь нормально: вызов my(vector&)
          your(sl);  // теперь нормально: вызов your(slist&)
        }

Поскольку тело функции существенно зависит от типа ее параметра,
надо написать каждую версию функций my() и your() независимо друг
от друга, что может быть хлопотно.
   С учетом всего изложенного конкретный тип, можно сказать, походит
на встроенные типы. Положительной стороной этого является тесная
связь между пользователем типа и его создателем, а также между
пользователями, которые создают объекты данного типа, и пользователями,
которые пишут функции, работающие с этими объектами. Чтобы
правильно использовать конкретный тип, пользователь должен
разбираться в нем детально. Обычно не существует каких-то
универсальных свойств, которыми обладали бы все конкретные типы
библиотеки, и что позволило бы пользователю, рассчитывая на эти
свойства, не тратить силы на изучение отдельных классов. Такова
плата за компактность программы и эффективность ее выполнения.
Иногда это вполне разумная плата, иногда нет. Кроме того, возможен
такой случай, когда отдельный конкретный класс проще понять и
использовать, чем более общий (абстрактный) класс. Именно так
бывает с классами, представляющими хорошо известные типы данных,
такие как массивы или списки.
    Тем не менее, укажем, что в идеале надо скрывать, насколько
возможно, детали реализации, пока это не ухудшает характеристики
программы. Большую помощь здесь оказывают функции-подстановки.
Если сделать открытыми переменные, являющиеся членами, с помощью описания
public, или непосредственно работать с ними с помощью функций, которые
устанавливают и получают значения этих переменных, то почти всегда
это приводит к плохому результату. Конкретные типы должны быть все-таки
настоящими типами, а не просто программной кучей с нескольким функциями,
добавленными ради удобства.

        13.3 Абстрактные типы

Самый простой способ ослабить связь между пользователем класса
и его создателем, а также между программами, в которых объекты
создаются, и программами, в которых они используются, состоит в введении
понятия абстрактных базовых классов. Эти классы представляют
интерфейс со множеством реализаций одного понятия. Рассмотрим
класс 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 нельзя включать операцию
индексирования, даже если для реализации конкретного множества
используется массив. Это приводит к ухудшению характеристик программы
из-за отсутствия ручной оптимизации. Далее, становится как правило
невозможной реализация функций подстановкой (если не считать каких-то
конкретных ситуаций, когда настоящий тип известен транслятору), поэтому
все полезные операции интерфейса, задаются как вызовы
виртуальных функций. Как и для конкретных типов здесь плата за
абстрактные типы иногда приемлема, иногда слишком высока.
    Подводя итог, перечислим каким целям должен служить абстрактный тип:
  [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()) {
                  // мой код
              }
              // ...
           }

Она хороша в общем случае, но представим,- стало известно,
что многие параметры множества представляют собой объекты типа
slist. Возможно также стал известен алгоритм перебора элементов, который
значительно эффективнее для списков, чем для произвольных
множеств. В результате эксперимента удалось выяснить, что именно
этот перебор является узким местом в системе. Тогда, конечно, имеет
смысл учесть в программе отдельно вариант с slist. Допустив возможность
определения истинного типа параметра, задающего множество, функцию
my(set&) можно записать так:

         void my(set& s)
         {
            if (ref_type_info(s) == static_type_info(slist_set)) {
               // сравнение двух представлений типа

               // s типа slist

               slist& sl = (slist&)s;
               for (T* p = sl.first(); p; p = sl.next()) {

                  // эффективный вариант в расчете на list

               }
          }
          else {

             for ( T* p = s.first(); p; p = s.next()) {

                  // обычный вариант для произвольного множества

              }
          }
          // ...
       }

Как только стал известен конкретный тип slist, стали
доступны определенные операции со списками, и даже стала возможна
реализация основных операций подстановкой.
   Приведенный вариант функции действует отлично, поскольку
slist - это конкретный класс, и действительно имеет смысл отдельно
разбирать вариант, когда параметр является slist_set. Рассмотрим
теперь такую ситуацию, когда желательно отдельно разбирать вариант как
для класса, так и для всех его производных классов. Допустим, мы
имеем класс dialog_box из $$13.4 и хотим узнать, является ли он
классом dbox_w_str. Поскольку может существовать много производных
классов от dbox_w_str, простую проверку на совпадение с ним
нельзя считать хорошим решением. Действительно, производные классы
могут представлять самые разные варианты запроса строки. Например,
один производный от dbox_w_str класс может предлагать пользователю
варианты строк на выбор, другой может обеспечить поиск в каталоге
и т.д. Значит, нужно проверять и на совпадение со всеми производными
от dbox_w_str классами. Это так же типично для узловых классов, как
проверка на вполне определенный тип типична для абстрактных классов,
реализуемых конкретными типами.

         void f(dialog_box& db)
         {
            dbox_w_str* dbws = ptr_cast(dbox_w_str, &db);
            if (dbws) {  // dbox_w_str
               // здесь можно использовать dbox_w_str::get_string()
            }
            else {

              // ``обычный'' dialog_box
            }

            // ...
          }

  Здесь "операция" приведения ptr_cast() свой второй параметр
(указатель) приводит к своему первому параметру (типу) при условии, что
указатель настроен на объект тип, которого совпадает с заданным
(или является производным классом от заданного типа). Для проверки
типа dialog_box используется указатель, чтобы после приведения его
можно было сравнить с нулем.
   Возможно альтернативное решение с помощью ссылки на dialog_box:

          void g(dialog_box& db)
          {
            try {
                dbox_w_str& dbws = ref_cast(dialog_box,db);

                // здесь можно использовать dbox_w_str::get_string()

             }
             catch (Bad_cast) {

                // ``обычный'' dialog_box

             }

             // ...
          }

Поскольку нет приемлемого представления нулевой ссылки, с которой
можно сравнивать, используется особая ситуация, обозначающая ошибку
приведения (т.е. случай, когда тип не есть dbox_w_str). Иногда
лучше избегать сравнения с результатом приведения.
   Различие функций ref_cast() и ptr_cast() служит хорошей
иллюстрацией различий между ссылками и указателями: ссылка обязательно
ссылается на объект, тогда как указатель может и не ссылаться,
поэтому для указателя часто нужна проверка.

        13.5.1 Информация о типе

В С++ нет иного стандартного средства получения динамической информации
о типе, кроме вызовов виртуальных функцийЬ.

Ь Хотя было сделано несколько предложений по расширению С++ в этом
направлении.

Смоделировать такое средство довольно просто и в большинстве
больших библиотек есть возможности динамических запросов о типе.
Здесь предлагается решение, обладающее тем полезным свойством,
что объем информации о типе можно произвольно расширять. Его можно
реализовать с помощью вызовов виртуальных функций, и оно может
входить в расширенные реализации С++.
      Достаточно удобный интерфейс с любым средством, поставляющим
информацию о типе, можно задать с помощью следующих операций:

        typeid static_type_info(type) // получить typeid для имени типа
        typeid ptr_type_info(pointer) // получить typeid для указателя
        typeid ref_type_info(reference) // получить typeid для ссылки
        pointer ptr_cast(type,pointer)  // преобразование указателя
        reference ref_cast(type,reference)  // преобразование ссылки

Пользователь класса может обойтись этими операциями, а создатель
класса должен предусмотреть в описаниях классов определенные
"приспособления", чтобы согласовать операции с реализацией
библиотеки.
   Большинство пользователей, которым вообще нужна динамическая
идентификация типа, может ограничиться операциями приведения
ptr_cast() и ref_cast(). Таким образом пользователь отстраняется от
дальнейших сложностей, связанных с динамической идентификацией
типа. Кроме того, ограниченное использование динамической информации
о типе меньше всего чревато ошибками.
   Если недостаточно знать, что операция приведения прошла успешно,
а нужен истинный тип (например, объектно-ориентированный
ввод-вывод), то можно использовать операции динамических запросов о типе:
static_type_info(), ptr_type_info() и ref_type_info(). Эти операции
возвращают объект класса typeid. Как было показано в примере с
set и slist_set, объекты класса typeid можно сравнивать. Для
большинства задач этих сведений о классе typeid достаточно. Но для
задач, которым нужна более полная информация о типе, в классе
typeid есть функция get_type_info():

          class typeid {
              friend class Type_info;
          private:
              const Type_info* id;
          public:
              typeid(const Type_info* p) : id(p) { }
              const Type_info* get_type_info() const { return id; }
              int operator==(typeid i) const ;
          };

Функция get_type_info() возвращает указатель на неменяющийся (const)
объект класса Type_info из typeid. Существенно, что объект
не меняется: это должно гарантировать, что динамическая информация
о типе отражает статические типы исходной программы. Плохо, если
при выполнении программы некоторый тип может изменяться.
   С помощью указателя на объект класса Type_info пользователь
получает доступ к информации о типе из typeid и, теперь его
программа начинает зависеть от конкретной системы динамических
запросов о типе и от структуры динамической информации о нем.
Но эти средства не входят в стандарт языка, а задать их с помощью
хорошо продуманных макроопределений непросто.

        13.5.2 Класс Type_info

В классе Type_info есть минимальный объем информации для реализации
операции ptr_cast(); его можно определить следующим образом:

          class Type_info {
              const char* n;       // имя
              const Type_info** b; // список базовых классов
          public:
              Type_info(const char* name, const Type_info* base[]);

              const char* name() const;
              Base_iterator bases(int direct=0) const;
              int same(const Type_info* p) const;
              int has_base(const Type_info*, int direct=0) const;
              int can_cast(const Type_info* p) const;

              static const Type_info info_obj;
              virtual typeid get_info() const;
              static typeid info();
          };

Две последние функции должны быть определены в каждом производном
от Type_info классе.
    Пользователь не должен заботиться о структуре объекта Type_info, и
она приведена здесь только для полноты изложения. Строка, содержащая
имя типа, введена для того, чтобы дать возможность поиска информации
в таблицах имен, например, в таблице отладчика. С помощью нее а также
информации из объекта Type_info можно выдавать более осмысленные
диагностические сообщения. Кроме того, если возникнет потребность
иметь несколько объектов типа Type_info, то имя может служить уникальным
ключом этих объектов.

          const char* Type_info::name() const
          {
            return n;
          }

          int Type_info::same(const Type_info* p) const
          {
            return this==p || strcmp(n,p->n)==0;
          }

          int Type_info::can_cast(const Type_info* p) const
          {
            return same(p) || p->has_base(this);
          }

Доступ к информации о базовых классах обеспечивается функциями
bases() и has_base(). Функция bases() возвращает итератор, который
порождает указатели на базовые классы объектов Type_info, а с
помощью функции has_base() можно определить является ли заданный класс
базовым для другого класса. Эти функции имеют необязательный параметр
direct, который показывает, следует ли рассматривать все базовые классы
(direct=0), или только прямые базовые классы (direct=1). Наконец,
как описано ниже, с помощью функций get_info() и info() можно
получить динамическую информацию о типе для самого класса Type_info.
     Здесь средство динамических запросов о типе сознательно
реализуется с помощью совсем простых классов. Так можно избежать
привязки к определенной библиотеке. Реализация в расчете на
конкретную библиотеку может быть иной. Можно, как всегда, посоветовать
пользователям избегать излишней зависимости от деталей реализации.
    Функция has_base() ищет базовые классы с помощью имеющегося в
Type_info списка базовых классов. Хранить информацию о том, является
ли базовый класс частным или виртуальным, не нужно, поскольку
все ошибки, связанные с ограничениями доступа или неоднозначностью,
будут выявлены при трансляции.

        class base_iterator {
          short i;
          short alloc;
          const Type_info* b;
        public:
          const Type_info* operator() ();
          void reset() { i = 0; }

          base_iterator(const Type_info* bb, int direct=0);
          ~base_iterator() { if (alloc) delete[] (Type_info*)b; }
       };

В следующем примере используется необязательный параметр для указания,
следует ли рассматривать все базовые классы (direct==0) или только прямые
базовые классы (direct==1).

      base_iterator::base_iterator(const Type_info* bb, int direct)
      {
        i = 0;

        if (direct) { // использование списка прямых базовых классов
           b = bb;
           alloc = 0;
           return;
        }

        // создание списка прямых базовых классов:

        // int n = число базовых
        b = new const Type_info*[n+1];
        // занести базовые классы в b

        alloc = 1;
        return;
      }

      const Type_info* base_iterator::operator() ()
      {
        const Type_info* p = &b[i];
        if (p) i++;
        return p;
      }

Теперь можно  задать операции запросов о типе с помощью макроопределений:

      #define static_type_info(T)  T::info()

      #define ptr_type_info(p)   ((p)->get_info())
      #define ref_type_info(r)   ((r).get_info())

      #define ptr_cast(T,p) \
         (T::info()->can_cast((p)->get_info()) ? (T*)(p) : 0)
      #define ref_cast(T,r) \
         (T::info()->can_cast((r).get_info()) \
             ? 0 : throw Bad_cast(T::info()->name()), (T&)(r))

Предполагается, что тип особой ситуации Bad_cast (Ошибка_приведения)
описан так:

      class Bad_cast {
        const char* tn;
        // ...
      public:
        Bad_cast(const char* p) : tn(p) { }
        const char* cast_to() { return tn; }
        //  ...
      };

    В разделе $$4.7 было сказано, что появление макроопределений
служит сигналом возникших проблем. Здесь проблема в том, что только
транслятор имеет непосредственный доступ к литеральным типам,
а макроопределения скрывают специфику реализации. По сути для хранения
информации для динамических запросов о типах предназначена таблица
виртуальных функций. Если реализация непосредственно поддерживает
динамическую идентификацию типа, то рассматриваемые операции можно
реализовать более естественно, эффективно и элегантно. В частности,
очень просто реализовать функцию ptr_cast(), которая преобразует
указатель на виртуальный базовый класс в указатель на его производные
классы.

        13.5.3 Как создать систему динамических запросов о типе

Здесь показано, как можно прямо реализовать динамические запросы
о типе, когда в трансляторе таких возможностей нет. Это достаточно
утомительная задача и можно пропустить этот раздел, так как в нем
есть только детали конкретного решения.
    Классы set и slist_set из $$13.3 следует изменить так, чтобы
с ними могли работать операции запросов о типе. Прежде всего, в
базовый класс set нужно ввести функции-члены, которые используют
операции запросов о типе:

       class set {
         public:
           static const Type_info info_obj;
           virtual typeid get_info() const;
           static typeid info();

           // ...
      };

При выполнении программы единственным представителем объекта типа
set является set::info_obj, который определяется так:

      const Type_info set::info_obj("set",0);

С учетом этого определения функции тривиальны:

     typeid set::get_info() const { return &info_obj; }
     typeid set::info() { return &info_obj; }
     typeid slist_set::get_info() const { return &info_obj; }
     typeid slist_set::info() { return &info_obj; }

Виртуальная функция get_info() будет предоставлять операции
ref_type_info() и ptr_type_info(), а статическая функция info()
- операцию static_type_info().
   При таком построении системы запросов о типе основная трудность
на практике состоит в том, чтобы для каждого класса объект типа
Type_info и две функции, возвращающие указатель на этот объект,
определялись только один раз.
    Нужно несколько изменить класс slist_set:

       class slist_set : public set, private slist {
          // ...
       public:
          static const Type_info info_obj;
          virtual typeid get_info() const;
          static typeid info();

          // ...
       };

       static const Type_info* slist_set_b[]
          = { &set::info_obj, &slist::info_obj, 0 };
       const Type_info slist_set::info_obj("slist_set",slist_set_b);

       typeid slist_set::get_info() const { return &info_obj; }
       typeid slist_set::info() { return &info_obj; }

        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 класса,
то она сработает неверно (действительно, вращать круг (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),
было подчеркнуто, что все функции базового класса реализуются
в самом базовом или в производном классе. Но существует и другой
способ построения классов. Рассмотрим, например, списки, массивы,
ассоциативные массивы, деревья и т.д. Естественно желание для всех
этих типов, часто называемых контейнерами, создать обобщающий их
класс, который можно использовать в качестве интерфейса с любым
из перечисленных типов. Очевидно, что пользователь не должен
знать детали, касающиеся конкретного контейнера. Но задача
определения интерфейса для обобщенного контейнера нетривиальна.
Предположим, что такой контейнер будет определен как абстрактный
тип, тогда какие операции он должен предоставлять? Можно предоставить
только те операции, которые есть в каждом контейнере, т.е.
пересечение множеств операций, но такой интерфейс будет слишком
узким. На самом деле, во многих, имеющих смысл случаях такое
пересечение пусто. В качестве альтернативного решения можно
предоставить объединение всех множеств операций и предусмотреть
динамическую ошибку, когда в этом интерфейсе к объекту
применяется "несуществующая" операция. Объединение интерфейсов классов,
представляющих  множество понятий, называется обширным интерфейсом.
Опишем "общий" контейнер объектов типа 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;
        // ...
      }

      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 {
             // Приехали!
             // А что теперь делать?
          }
        }

Оба способа обнаружения ошибки, показанные на этих примерах,
приводят к программе с "раздутым" кодом и низкой скоростью
выполнения. Поэтому обычно просто игнорируют возможные ошибки
в надежде, что пользователь на них не натолкнется. Но задача от этого
не упрощается, ведь полное тестирование затруднительно и требует
многих усилий .
   Поэтому, если целью является программа с хорошими характеристиками,
или требуются высокие гарантии корректности программы, или, вообще,
есть хорошая альтернатива, лучше не использовать обширные интерфейсы.
Кроме того, использование обширного интерфейса нарушает
взаимнооднозначное соответствие между классами и понятиями, и тогда
начинают вводить новые производные классы просто для удобства
реализации.

        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 Управляющие классы

Концепция абстрактного класса дает эффективное средство для разделения
интерфейса и его реализации. Мы применяли эту концепцию и получали
постоянную связь между интерфейсом, заданным абстрактным типом,
и реализацией, представленной конкретным типом. Так, невозможно
переключить абстрактный итератор с одного класса-источника на
другой, например, если исчерпано множество (класс set), невозможно
перейти на потоки.
    Далее, пока мы работаем с объектами абстрактного типа с помощью
указателей или ссылок, теряются все преимущества виртуальных
функций. Программа пользователя начинает зависеть от конкретных классов
реализации. Действительно, не зная размера объекта, даже при
абстрактном типе нельзя разместить объект в стеке, передать как параметр
по значению или разместить как статический. Если работа с объектами
организована через указатели или ссылки, то задача распределения
памяти перекладывается на пользователя ($$13.10).
   Существует и другое ограничение, связанное с использованием абстрактных
типов. Объект такого класса всегда имеет определенный размер,
но классы, отражающие реальное понятие, могут требовать память
разных размеров.
   Есть распространенный прием преодоления этих трудностей, а именно,
разбить отдельный объект на две части: управляющую, которая определяет
интерфейс объекта, и содержательную, в которой находятся все
или большая часть атрибутов объекта. Связь между двумя частями
реализуется с помощью указателя в управляющей части на содержательную
часть. Обычно в управляющей части кроме указателя есть
и другие данные, но их немного. Суть в том, что состав управляющей
части не меняется при изменении содержательной части, и она
настолько мала, что можно свободно работать с самими объектами,
а не с указателями или ссылками на них.

        управляющая часть           содержательная часть

Простым примером управляющего класса может служить класс string из
$$7.6. В нем содержится интерфейс, контроль доступа и управление
памятью для содержательной части. В этом примере управляющая и
содержательная части представлены конкретными типами, но чаще
содержательная часть представляется абстрактным классом.
   Теперь вернемся к абстрактному типу set из $$13.3. Как можно
определить управляющий класс для этого типа, и какие это даст плюсы
и минусы? Для данного класса set можно определить управляющий
класс просто перегрузкой операции ->:

         class set_handle {
            set* rep;
         public:
            set* operator->() { return rep; }

            set_handler(set* pp) : rep(pp) { }
         };

Это не слишком влияет на работу с множествами, просто передаются
объекты типа set_handle вместо объектов типа set& или set*,
например:

         void my(set_handle s)
         {
           for (T* p = s->first(); p; p = s->next())
           {
              // ...
           }
           // ...
         }

         void your(set_handle s)
         {
           for (T* p = s->first(); p; p = s->next())
           {
             // ...
           }
           // ...
         }

         void user()
         {
           set_handle sl(new slist_set);
           set_handle v(new vector_set v(100));

           my(sl);
           your(v);

           my(v);
           your(sl);
         }

Если классы set и set_handle разрабатывались совместно,легко
реализовать подсчет числа создаваемых множеств:

         class set {
         friend class set_handle;
         protected:
           int handle_count;
         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;

           set() : handle_count(0) { }
         };

Чтобы подсчитать число объектов данного типа set, в управляющем
классе нужно увеличивать или уменьшать значение счетчика
set_handle:

         class set_handle {
           set* rep;
         public:
           set* operator->() { return rep; }

         set_handle(set* pp)
            : rep(pp) { pp->handle_count++; }
         set_handle(const set_handle& r)
            : rep(r.rep) { rep->handle_count++; }

         set_handle& operator=(const set_handle& r)
         {
            rep->handle_count++;
            if (--rep->handle_count == 0) delete rep;
            rep = r.rep;
            return *this;
          }

          ~set_handle()
             { if (--rep->handle_count == 0) delete rep; }
        };

Если все обращения к классу set обязательно идут через
set_handle, пользователь может не беспокоиться о распределении
памяти под объекты типа set.
    На практике иногда приходится извлекать указатель на содержательную
часть из управляющего класса и пользоваться непосредственно им.
Можно, например, передать такой указатель функции, которая ничего
не знает об управляющем классе. Если функция не уничтожает объект,
на который она получила указатель, и если она не сохраняет указатель
для дальнейшего использования после возврата, никаких ошибок быть
не должно. Может оказаться полезным переключение управляющего класса
на другую содержательную часть:

          class set_handle {
            set* rep;
          public:
            // ...

          set* get_rep() { return rep; }

          void bind(set* pp)
          {
            pp->handle_count++;
            if (--rep->handle_count == 0) delete rep;
            rep = pp;
          }
       };

Создание новых производных от set_handle классов обычно не имеет
особого смысла, поскольку это - конкретный тип без виртуальных
функций. Другое дело - построить управляющий класс для семейства
классов, определяемых одним базовым. Полезным приемом будет
создание производных от такого управляющего класса. Этот прием можно
применять как для узловых классов, так и для абстрактных типов.
   Естественно задавать управляющий класс как шаблон типа:

        template<class T> class handle {
           T* rep;
        public:
           T* operator->() { return rep; }
           // ...
        };

Но при таком подходе требуется взаимодействие между
управляющим и "управляемым" классами. Если управляющий и управляемые
классы разрабатываются совместно, например, в процессе создания
библиотеки, то это может быть допустимо. Однако, существуют и другие
решения ($$13.10).
     За счет перегрузки операции -> управляющий класс получает
возможность контроля и выполнения каких-то операций при каждом
обращении к объекту. Например, можно вести подсчет частоты
использования объектов через управляющий класс:

        template<class T>
           class Xhandle {
             T* rep;
             int count;
           public:
             T* operator->() { count++; return rep; }

             // ...
           };

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

           class set_controller {
             set* rep;
             // ...
           public:

             lock();
             unlock();

             virtual void insert(T* p)
               { lock(); rep->insert(p); unlock(); }
             virtual void remove(T* p)
               { lock(); rep->remove(p); unlock(); }

             virtual int is_member(T* p)
               { return rep->is_member(p); }

             virtual T* first() { return rep->first(); }
             virtual T* next() { return rep->next(); }

             // ...
           };

Писать функции-переходники для всего интерфейса утомительно (а значит
могут появляться ошибки), но не трудно и это не ухудшает
характеристик  программы.
   Заметим, что не все функции из set следует блокировать. Как
показывает опыт автора, типичный случай, когда операции до и после
обращения к объекту надо выполнять не для всех, а только для некоторых
функций-членов. Блокировка всех операций, как это делается в
мониторах некоторых операционных систем, является избыточной и может
существенно ухудшить параллельный режим выполнения.
   Переопределив все функции интерфейса в управляющем классе, мы
получили по сравнению с приемом перегруз