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

        10.3.3 Ввод пользовательских типов

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

     istream& operator>>(istream& s, complex& a)
     /*
        формат input рассчитан на complex; "f" обозначает float:
            f
            ( f )
            ( f , f )
     */
     {
        double re = 0, im = 0;
        char   c = 0;

        s >> c;
        if (c == '(') {
            s >> re >> c;
            if (c == ',') s >> im >> c;
            if (c != ')') s.clear(ios::badbit); // установим состояние
        }
        else {
            s.putback(c);
            s >> re;
        }

        if (s) a = complex(re,im);
        return s;
     }

Несмотря на сжатость кода, обрабатывающего ошибки, на самом деле
учитывается большая часть ошибок. Инициализация локальной переменной
с нужна для того, чтобы в нее не попало случайное значение, например
'(', в случае неудачной операции. Последняя проверка состояния потока
гарантирует, что параметр a получит значение только при успешном вводе.
     Операция, устанавливающая состояние потока, названа clear()
(здесь clear - ясный, правильный),
поскольку чаще всего она используется для восстановления состояния потока
как good(); значением по умолчанию для параметра ios::clear() является
ios::goodbit.

        10.4 Форматирование

Все примеры из 10.2 содержали неформатированный вывод, который являлся
преобразованием объекта в последовательность символов, задаваемую
стандартными правилами, длина которой также определяется этими
правилами. Часто программистам требуются более развитые возможности.
Так, возникает потребность контролировать размер памяти, необходимой
для операции вывода, и формат, используемый для выдачи чисел.
Точно так же допустимо управление некоторыми аспектами ввода.

        10.4.1 Класс ios

Большинство средств управления вводом-выводом сосредоточены в классе
ios, который является базовым для ostream и istream. По сути здесь
находится управление связью между istream или ostream и буфером,
используемым для операций ввода-вывода. Именно  класс ios контролирует:
как символы попадают в буфер и как они выбираются оттуда. Так, в классе
ios есть член, содержащий информацию об используемой при чтении или
записи целых чисел системы счисления (десятичная, восьмеричная или
шестнадцатеричная), о  точности  вещественных чисел и т.п., а также
функции для проверки и установки значений переменных, управляющих
потоком.

     class ios {
         //...
     public:
         ostream* tie(ostream* s);   // связать input и output
         ostream* tie();             // возвратить "tie"

     int width(int w);               // установить поле width
     int width() const;

     char fill(char);                // установить символ заполнения
     char fill() const;              // вернуть символ заполнения

     long flags(long f);
     long flags() const;

     long setf(long setbits, long field);
     long setf(long);
     long unsetf(long);

     int precision(int);             // установить точность для float
     int precision() const;
     int rdstate(); const;          // состояния потоков, см. $$10.3.2
     int eof() const;
     int fail() const;
     int bad() const;
     int good() const;
     void clear(int i=0);

     //...
  };

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

        10.4.1.1 Связывание потоков

Функция tie() может установить и разорвать связь между ostream и
istream. Рассмотрим пример:

       main()
       {
         String s;
         cout << "Password: ";
         cin >> s;
         // ...
        }

Как можно гарантировать, что приглашение Password: появится на
экране прежде, чем выполниться операция чтения? Вывод в cout и ввод
из cin буферизуются, причем независимо, поэтому Password: появится
только по завершении программы, когда закроется буфер вывода.
     Решение состоит в том, чтобы связать cout и cin с помощью
операции cin.tie(cout).
Если ostream связан с потоком istream, то буфер вывода выдается при
каждой операции ввода над istream. Тогда операции

        cout << "Password: ";
        cin >> s;

эквивалентны

        cout << "Password: ";
        cout.flush();
        cin >> s;

Обращение is.tie(0) разрывает связь между потоком is и потоком, с
которым он был связан, если такой был. Подобно другим потоковым
функциям, устанавливающим определенное значение, tie(s) возвращает
предыдущее значение, т.е. значение связанного потока перед обращением
или 0. Вызов без параметра tie() возвращает текущее значение.

        10.4.1.2 Поля вывода

Функция width() устанавливает минимальное число символов, использующееся
в последующей операции вывода числа или строки. Так в результате
следующих операций

        cout.width(4);
        cout << '(' << 12 << ')';

получим число 12 в поле размером 4 символа, т.е.

        (  12)

Заполнение поля заданными символами или выравнивание можно установить с
помощью функции fill(), например:

        cout.width(4);
        cout.fill('#');
        cout << '(' << "ab" << ')';

напечатает

        (##ab)

По умолчанию поле заполняется пробелами, а размер поля по умолчанию
есть 0, что означает "столько символов, сколько нужно". Вернуть размеру
поля стандартное значение можно с помощью вызова

        cout.width(0); // ``столько символов, сколько надо''

Функция width() задает минимальное число символов. Если появится больше
символов, они будут напечатаны все, поэтому

        cout.width(4);
        cout << '(' << "121212" << ")\n";

напечатает

        (121212)

Причина, по которой разрешено переполнение поля, а не усечение вывода,
в том, чтобы избежать зависания при выводе. Лучше получить правильную
выдачу, выглядящую некрасиво, чем красивую выдачу, являющуюся
неправильной.
      Вызов width() влияет только на одну следующую за ним операцию
вывода, поэтому

        cout.width(4);
        cout.fill('#');
        cout << '(' << 12 << "),(" << '(' <<12 << ")\n";

напечатает

        (##12),(12)

а не

        (##12),(##12)

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

        (##12#),(##12#
        )

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

        10.4.1.3 Состояние формата

В классе ios содержится состояние формата, которое управляется
функциями flags() и setf(). По сути эти функции нужны, чтобы
установить или отменить следующие флаги:

     class ios {
     public:
            // управляющие форматом флаги:
        enum {
            skipws=01,          // пропуск обобщенных пробелов для input
                                // поле выравнивания:
            left=02,            // добавление перед значением
            right=04,           // добавление после значения
            internal=010,       // добавление между знаком и значением
                                // основание целого:
            dec=020,            // восьмеричное
            oct=040,            // десятичное
            hex=0100,           // шестнадцатеричное
            showbase=0200,      // показать основание целого
            showpoint=0400,     // выдать нули в конце
            uppercase=01000,    // 'E', 'X' , а не 'e', 'x'
            showpos=02000,      //  '+' для положительных чисел
                                // запись числа типа float:
            scientific=04000,   // .dddddd Edd
            fixed=010000,       // dddd.dd
                                // сброс в выходной поток:
            unitbuf=020000,     // после каждой операции
            stdio=040000        // после каждого символа
         };
         //...
     };

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

       const int my_io_options =
          ios::left|ios::oct|ios::showpoint|ios::fixed;

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

       cout.flags(my_io_options);

а также просто передавать между функциями одной программы:

       void your_function(int ios_options);

       void my_function()
       {
          // ...
         your_function(my_io_options);
         // ...
       }

Множество флагов можно установить с помощью функции flags(), например:

       void your_function(int ios_options)
       {
        int old_options = cout.flags(ios_options);
        // ...
        cout.flags(old_options);  // reset options
        }

Функция flags() возвращает старое значение множества флагов. Это
позволяет переустановить значения всех флагов, как показано выше,
а также задать значение отдельному флагу. Например вызов

       myostream.flags(myostream.flags()|ios::showpos);

заставляет класс myostream выдавать положительные числа со знаком
+ и, в то же время, не меняет значения других флагов. Получается
старое значение множества флагов, к которому добавляется с помощью
операции | флаг showpos. Функция setf() делает то же самое,
поэтому эквивалентная запись имеет вид

       myostream.setf(ios::showpos);

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

        10.4.1.4 Вывод целых

Прием задания нового значения множества флагов с помощью операции | и
функций flags() и setf() работает только тогда, когда один бит определяет
значение флага. Не такая ситуация при задании системы счисления целых
или вида выдачи вещественных. Здесь значение, определяющее вид выдачи,
нельзя задать одним битом или комбинацией отдельных битов.
     Решение, принятое в <iostream.h>, сводится к использованию
версии функции setf(), работающей со вторым "псевдопараметром", который
показывает какой именно флаг мы хотим добавить к новому значению.

Поэтому обращения

       cout.setf(ios::oct,ios::basefield); // восьмеричное
       cout.setf(ios::dec,ios::basefield); // десятичное
       cout.setf(ios::hex,ios::basefield); // шестнадцатеричное

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

     cout << 1234 << ' ';  // десятичное по умолчанию
     cout << 1234 << ' ';

     cout.setf(ios::oct,ios::basefield);  // восьмеричное
     cout << 1234 << ' ';
     cout << 1234 << ' ';

     cout.setf(ios::hex,ios::basefield);  // шестнадцатеричное
     cout << 1234 << ' ';
     cout << 1234 << ' ';

напечатает

       1234 1234 2322 2322 4d2 4d2

Если появится необходимость указывать систему счисления для каждого
выдаваемого числа, следует установить флаг showbase. Поэтому, добавив
перед приведенными выше обращениями

       cout.setf(ios::showbase);

мы получим

       1234 1234 02322 02322 0x4d2 0x4d2

Стандартные манипуляторы, приведенные в $$10.4.2.1, предлагают более
элегантный способ определения системы счисления при выводе целых.

        10.4.1.5 Выравнивание полей

С помощью обращений к setf() можно управлять расположением символов
в пределах поля:

       cout.setf(ios::left,ios::adjustfield);     // влево
       cout.setf(ios::right,ios::adjustfield);    // вправо
       cout.setf(ios::internal,ios::adjustfield); // внутреннее

Будет установлено выравнивание в поле вывода, определяемом функцией
ios::width(), причем не затрагивая других компонентов состояния потока.
       Выравнивание можно задать следующим образом:

     cout.width(4);
     cout << '(' << -12 << ")\n";

     cout.width(4);
     cout.setf(ios::left,ios::adjustfield);
     cout << '(' << -12 << ")\n";

     cout.width(4);
     cout.setf(ios::internal,ios::adjustfield);
     cout << '(' << -12 << "\n";

что выдаст

       ( -12)
       (-12 )
       (- 12)

Если установлен флаг выравнивания internal (внутренний), то символы
добавляются между знаком и величиной. Как видно, стандартным является
выравнивание вправо.

        10.4.1.6 Вывод плавающих чисел.

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

       cout.setf(ios::scientific,ios::floatfield);
       cout.setf(ios::fixed,ios::floatfield);
       cout.setf(0,ios::floatfield);   // вернуться к стандартному

установят вид печати вещественных чисел без изменения других
компонентов состояния потока.
Например:

     cout << 1234.56789 << '\n';

     cout.setf(ios::scientific,ios::floatfield);
     cout << 1234.56789 << '\n';

     cout.setf(ios::fixed,ios::floatfield);
     cout << 1234.56789 << '\n';

напечатает

       1234.57
       1.234568e+03
       1234.567890

После точки печатается n цифр, как задается в обращении

       cout.precision(n)

По умолчанию n равно 6. Вызов функции precision влияет на все операции
ввода-вывода с вещественными до следующего обращения к precision,
поэтому

     cout.precision(8);
     cout << 1234.56789 << '\n';
     cout << 1234.56789 << '\n';

     cout.precision(4);
     cout << 1234.56789 << '\n';
     cout << 1234.56789 << '\n';

выдаст

      1234.5679
      1234.5679
      1235
      1235

Заметьте, что происходит округление, а не отбрасывание дробной части.
      Стандартные манипуляторы, введенные в $$10.4.2.1, предлагают
более элегантный способ задания формата вывода вещественных.

        10.4.2 Манипуляторы

      К ним относятся разнообразные операции, которые приходится
применять сразу перед или сразу после операции ввода-вывода. Например:

      cout << x;
      cout.flush();
      cout << y;

      cin.eatwhite();
      cin >> x;

Если писать отдельные операторы как выше, то логическая связь между
операторами неочевидна, а если утеряна логическая связь, программу
труднее понять.
      Идея манипуляторов позволяет такие операции как flush() или
eatwhite() прямо вставлять в список операций ввода-вывода. Рассмотрим
операцию flush(). Можно определить класс с операцией operator<<(), в
котором вызывается flush():

      class Flushtype { };

      ostream& operator<<(ostream& os, Flushtype)
      {
         return flush(os);
      }

определить объект такого типа

      Flushtype FLUSH;

и добиться выдачи буфера, включив FLUSH в список объектов, подлежащих
выводу:

      cout << x << FLUSH << y << FLUSH ;

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

        typedef ostream& (*Omanip) (ostream&);

        ostream& operator<<(ostream& os, Omanip f)
        {
          return f(os);
        }

Здесь операция вывода использует параметры типа "указатель на функцию,
имеющую аргумент ostream& и возвращающую ostream&". Отметив, что flush()
есть функция типа "функция с аргументом ostream& и возвращающая
ostream&", мы можем писать

        cout << x << flush << y << flush;

получив вызов функции flush(). На самом деле в файле <iostream.h>
функция flush() описана как

        ostream& flush(ostream&);

а в классе есть операция operator<<, которая использует указатель на
функцию, как указано выше:

        class ostream : public virtual ios {
           // ...
        public:
          ostream& operator<<(ostream& ostream& (*)(ostream&));
          // ...
        };

В приведенной ниже строке буфер выталкивается в поток cout дважды в
подходящее время:

        cout << x << flush << y << flush;

Похожие определения существуют и для класса istream:

        istream& ws(istream& is ) { return is.eatwhite(); }

        class istream : public virtual ios {
         // ...
        public:
          istream& operator>>(istream&, istream& (*) (istream&));
          // ...
        };

поэтому в строке

        cin >> ws >> x;

действительно обобщенные пробелы будут убраны до попытки чтения в x.
Однако, поскольку по умолчанию для операции >>  пробелы "съедаются" и
так, данное применение ws() избыточно.
        Находят применение и манипуляторы с параметрами. Например,
может появиться желание с помощью

        cout << setprecision(4) << angle;

напечатать значение вещественной переменной angle с точностью до
четырех знаков после точки.
        Для этого нужно уметь вызывать функцию, которая установит
значение переменной, управляющей в потоке точностью вещественных.
Это достигается, если определить setprecision(4) как объект, который
можно "выводить" с помощью operator<<():

     class Omanip_int {
         int i;
         ostream& (*f) (ostream&,int);
     public:
         Omanip_int(ostream& (*ff) (ostream&,int), int ii)
             : f(ff), i(ii) { }
         friend ostream& operator<<(ostream& os, Omanip& m)
             { return m.f(os,m.i); }
      };

Конструктор Omanip_int хранит свои аргументы в i и f, а с помощью
operator<< вызывается f() с параметром i. Часто объекты таких классов
называют объект-функция. Чтобы результат строки

         cout << setprecision(4) << angle

был таким, как мы хотели, необходимо чтобы обращение  setprecision(4)
создавало безымянный объект класса Omanip_int, содержащий значение 4
и указатель на функцию, которая устанавливает в потоке ostream значение
переменной, задающей точность вещественных:

     ostream& _set_precision(ostream&,int);

     Omanip_int setprecision(int i)
     {
         return Omanip_int(&_set_precision,i);
     }

Учитывая сделанные определения, operator<<() приведет к вызову
precision(i).
        Утомительно определять классы наподобие Omanip_int для всех
типов аргументов, поэтому  определим шаблон типа:

     template<class T> class OMANIP {
         T i;
         ostream& (*f) (ostream&,T);
     public:
         OMANIP(ostream (*ff) (ostream&,T), T ii)
             : f(ff), i(ii) { }

     friend ostream& operator<<(ostream& os, OMANIP& m)
         { return m.f(os,m.i) }
     };

С помощью OMANIP пример с установкой точности можно сократить так:

     ostream& precision(ostream& os,int)
     {
         os.precision(i);
         return os;
     }

     OMANIP<int> setprecision(int i)
     {
         return OMANIP<int>(&precision,i);
     }

В файле  <iomanip.h>  можно найти шаблон типа OMANIP,  его двойник для
istream - шаблон типа SMANIP, а SMANIP - двойник для ioss.
Некоторые из стандартных манипуляторов,  предлагаемых поточной
библиотекой, описаны ниже. Отметим,что программист может определить новые
необходимые ему манипуляторы, не затрагивая определений istream,
ostream, OMANIP или SMANIP.
       Идею манипуляторов предложил А. Кениг. Его вдохновили процедуры
разметки (layout ) системы ввода-вывода Алгола68. Такая техника имеет
много интересных приложений помимо ввода-вывода. Суть ее в том, что
создается объект, который можно передавать куда угодно и который
используется как функция. Передача объекта является более гибким
решением, поскольку детали выполнения частично определяются создателем
объекта, а частично тем, кто к нему обращается.

        10.4.2.1 Стандартные манипуляторы ввода-вывода

Это следующие манипуляторы:

     // Simple manipulators:
     ios& oct(ios&);  // в восьмеричной записи
     ios& dec(ios&);  // в десятичной записи
     ios& hex(ios&);  // в шестнадцатеричной записи
     ostream& endl(ostream&);   // добавить '\n' и вывести
     ostream& ends(ostream&);   // добавить '\0' и вывести
     ostream& flush(ostream&);  // выдать поток

     istream& ws(istream&);     // удалить обобщенные пробелы

     // Манипуляторы имеют параметры:

     SMANIP<int>  setbase(int b);
     SMANIP<int>  setfill(int f);
     SMANIP<int>  setprecision(int p);
     SMANIP<int>  setw(int w);
     SMANIP<long> resetiosflags(long b);
     SMANIP<long> setiosflags(long b);

Например,

       cout << 1234 << ' '
            << hex  << 1234 << ' '
            << oct  << 1234 << endl;

напечатает

       1234 4d2 2322

и

       cout << setw(4) << setfill('#') << '(' << 12 << ")\n";
       cout << '(' << 12 << ")\n";

напечатает

       (##12)
       (12)

Не забудьте включить файл <iomanip.h>, если используете манипуляторы с
параметрами.

        10.4.3 Члены ostream

В классе ostream есть лишь несколько функций для управления выводом,
большая часть таких функций находится в классе ios.

     class ostream : public virtual ios {
         //...
     public:
         ostream& flush();

         ostream&  seekp(streampos);
         ostream&  seekp(streamoff, seek_dir);
         streampos tellp();
         //...
     };

Как мы уже говорили, функция flush() опустошает буфер в выходной поток.
Остальные функции используются для позиционирования в ostream при
записи. Окончание на букву p указывает, что именно позиция используется
при выдаче символов в заданный поток. Конечно эти функции имеют смысл,
только если поток присоединен к чему-либо, что допускает
позиционирование, например файл. Тип streampos представляет позицию символа
в файле, а тип streamoff представляет смещение относительно позиции,
заданной seek_dir. Все они определены в классе ios:

     class ios {
         //...
         enum seek_dir {
            beg=0,  // от начала файла
            cur=1,  // от текущей позиции в файле
            end=2   // от конца файла
         };
         //...
     };

Позиции в потоке отсчитываются от 0, как если бы файл был массивом из
n символов:

         char file[n-1];

и если fout присоединено к file, то

         fout.seek(10);
         fout<<'#';

поместит # в file[10].

        10.4.4 Члены istream

Как и для ostream, большинство функций форматирования и управления
вводом находится не в классе iostream, а в базовом классе ios.

     class istream : public virtual ios {
         //...
     public:
         int         peek()
         istream&    putback(char c);

         istream&    seekg(streampos);
         istream&    seekg(streamoff, seek_dir);
         streampos   tellg();
         //...
     };

Функции позиционирования работают как и их двойники из ostream.
Окончание на букву g показывает, что именно позиция используется при
вводе символов из заданного потока. Буквы p и g нужны, поскольку
мы можем создать производный класс iostreams из классов ostream и
istream, и в нем необходимо следить за позициями ввода и вывода.
    С помощью функции peek() программа может узнать следующий символ,
подлежащий вводу, не затрагивая результата последующего чтения. С
помощью функции putback(), как показано в $$10.3.3, можно вернуть
ненужный символ назад в поток, чтобы он был прочитан в другое время.

        10.5 Файлы и потоки

Ниже приведена программа копирования одного файла в другой. Имена
файлов берутся из командной строки программы:

     #include <fstream.h>
     #include <libc.h>

     void error(char* s, char* s2 ="")
     {
        cerr << s << ' ' << s2 << '\n';
        exit(1);
     }

     int main(int argc, char* argv[])
     {
         if (argc != 3) error("wrong number of arguments");

         ifstream from(argv[1]);
         if (!from) error("cannot open input file",argv[1]);

         ostream to(argv[2]);
         if (!to) error("cannot open output file",argv[2]);

         char ch;
         while (from.get(ch)) to.put(ch);

         if (!from.eof() || to.bad())
            error("something strange happened");

         return 0;
      }

Для открытия выходного файла создается объект класса ofstream -
выходной поток файла, использующий в качестве аргумента имя файла.
Аналогично, для открытия входного файла создается объект класса
ifstream - входной файловый поток, также использующий в качестве
аргумента имя файла. В обоих случаях следует  проверить состояние
созданного объекта, чтобы убедиться в успешном открытии файла, а
если это не так, операции завершатся не успешно, но корректно.
      По умолчанию ifstream всегда открывается на чтение, а ofstream
открывается на запись. В ostream и в istream можно использовать
необязательный второй аргумент, указывающий иные режимы открытия:

     class ios {
     public:
         //...
         enum open_mode {
            in=1,            // открыть на чтение
            out=2,           // открыть как выходной
            ate=4,           // открыть и переместиться в конец файла
            app=010,         // добавить
            trunc=020,       // сократить файл до нулевой длины
            nocreate=040,    // неудача, если файл не существует
            noreplace=0100   // неудача, если файл существует
         };
         //...
     };

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

     void f()
     {
         ofstream mystream(name,ios::out|ios::nocreate);

         if (ofstream.bad()) {
             //...
         }
         //...
     }

Также можно открыть файл сразу на чтение и запись:

       fstream dictionary("concordance", ios::in|ios::out);

Все операции, допустимые для ostream и ostream, можно применять к
fstream. На самом деле, класс fstream является производным от iostream,
который является, в свою очередь, производным от istream и ostream.
Причина, по которой информация по буферизации и форматированию для
ostream и istream находится в виртуальном базовом классе ios, в том,
чтобы заставить действовать всю эту последовательность производных
классов. По этой же причине операции позиционирования в istream и
ostream имеют разные имена - seekp() и seekg(). В iostream есть
отдельные позиции для чтения и записи.

        10.5.1 Закрытие потоков

Файл может быть закрыт явно, если вызвать close() для его потока:

      mystream.close();

Но это неявно делает деструктор потока, так что явный вызов close()
может понадобиться, если только файл нужно закрыть до достижения
конца области определенности потока.
      Здесь возникает вопрос, как реализация может обеспечить
создание предопределенных потоков cout, cin и cerr до их первого
использования и закрытие их только после последнего использования.
Конечно, разные реализации библиотеки потоков из <iostream.h> могут
по-разному решать эту задачу. В конце концов, решение - это
прерогатива реализации, и оно должно быть скрыто от пользователя. Здесь
приводится только один способ, примененный только в одной реализации,
но он достаточно общий, чтобы гарантировать правильный порядок
создания и уничтожения глобальных объектов различных типов.
      Основная идея в том, чтобы определить вспомогательный класс,
который по сути служит счетчиком, следящим за тем, сколько раз
<iostream.h> был включен в раздельно компилировавшиеся программные
файлы:

     class Io_init {
         static int count;
         //...
     public:
         Io_init();
         ^Io_init();
     };

     static Io_init io_init ;

Для каждого программного файла определен свой объект с именем io_init.
Конструктор для объектов io_init использует Io_init::count как первый
признак того, что действительная инициализация глобальных объектов
потоковой библиотеки ввода-вывода сделана в точности один раз:

     Io_init::Io_init()
     {
        if (count++ == 0) {
            // инициализировать cout
            // инициализировать cerr
            // инициализировать cin
            // и т.д.
        }
     }

Обратно, деструктор для объектов io_init использует Io_count, как
последнее указание на то, что все потоки закрыты:

     Io_init::^Io_init()
     {
        if (--count == 0) {
            // очистить cout (сброс, и т.д.)
            // очистить cerr (сброс, и т.д.)
            // очистить cin
            // и т.д.
        }
      }

Это общий прием работы с библиотеками, требующими инициализации и
удаления глобальных объектов. Впервые в С++ его применил Д. Шварц.
В системах, где при выполнении все программы размещаются в основной
памяти, для этого приема нет помех. Если это не так, то накладные
расходы, связанные с вызовом в память каждого программного файла
для выполнения функций инициализации, будут заметны. Как всегда,
лучше, по возможности, избегать глобальных объектов. Для классов,
в которых каждая операция значительна по объему выполняемой работы,
чтобы гарантировать инициализацию, было бы разумно проверять такие
первые признаки (наподобие Io_init::count) при каждой операции.
Однако, для потоков такой подход был бы излишне расточительным.

        10.5.2 Строковые потоки

Как было показано, поток может быть привязан к файлу, т.е. массиву
символов, хранящемуся не в основной памяти, а, например, на диске. Точно
так же поток можно привязать к массиву символов в основной памяти.
Например, можно воспользоваться выходным строковым потоком ostrstream
для форматирования сообщений, не подлежащих немедленной печати:

     char* p = new char[message_size];
     ostrstream ost(p,message_size);
     do_something(arguments,ost);
     display(p);

С помощью стандартных операций вывода функция do_something может писать
в поток ost, передавать ost подчиняющимся ей функциям и т.п. Контроль
переполнения не нужен, поскольку ost знает свой размер и при заполнении
перейдет в состояние, определяемое fail(). Затем функция display может
послать сообщение в "настоящий" выходной поток. Такой прием наиболее
подходит в тех случаях, когда окончательная операция вывода
предназначена для записи на более сложное устройство, чем традиционное,
ориентированное на последовательность строк, выводное устройство.
Например, текст из ost может быть помещен в фиксированную область на экране.
        Аналогично, istrstream является вводным строковым потоком,
читающим из последовательности символов, заканчивающейся нулем:

     void word_per_line(char v[], int sz)
     /*
        печатать "v" размером "sz" по одному слову в строке
     */
     {
        istrstream ist(v,sz);  // создать istream для v
        char b2[MAX];          // длиннее самого длинного слова
        while (ist>>b2) cout <<b2 << "\n";
      }

Завершающий нуль считается концом файла.
        Строковые потоки описаны в файле <strstream.h>.

        10.5.3 Буферизация

Все операции ввода-вывода были определены без всякой связи с типом
файла, но нельзя одинаково работать со всеми устройствами без учета
алгоритма буферизации. Очевидно, что потоку ostream, привязанному к
строке символов, нужен не такой буфер, как ostream, привязанному к
файлу. Такие вопросы решаются созданием во время инициализации разных
буферов для потоков разных типов. Но существует только один набор
операций над этими типами буферов, поэтому в ostream нет функций, код
которых учитывает различие буферов. Однако, функции, следящие за
переполнением и обращением к пустому буферу, являются виртуальными.
Это хороший пример применения виртуальных функций для единообразной
работы с эквивалентными логически, но различно реализованными
структурами, и они вполне справляются с требуемыми алгоритмами буферизации.
Описание буфера потока в файле <iostream.h> может выглядеть следующим
образом:

     class streambuf {     // управление буфером потока
     protected:
         char* base;       // начало буфера
         char* pptr;       // следующий свободный байт
         char* gptr;       // следующий заполненный байт
         char* eptr;       // один из указателей на конец буфера
         char  alloc;      // буфер, размещенный с помощью "new"
         //...
         // Опустошить буфер:
         // Вернуть EOF при ошибке, 0 - удача
     virtual int overflow(int c = EOF);

         // Заполнить буфер:
         // Вернуть EOF в случае ошибки или конца входного потока,
         // иначе вернуть очередной символ
      virtual int underflow();
      //...
      public:
          streambuf();
          streambuf(char* p, int l);
          virtual ~streambuf();

          int snextc()       // получить очередной символ
          {
              return (++gptr==pptr) ? underflow() : *gptr&0377;
          }
          int allocate();    // отвести память под буфер
          //...
     };

Подробности реализации класса streambuf приведены здесь только для
полноты представления. Не предполагается, что есть общедоступные
реализации, использующие именно эти имена. Обратите внимание на
определенные здесь указатели, управляющие буфером; с их помощью
простые посимвольные операции с потоком можно определить максимально
эффективно (и причем однократно) как функции-подстановки. Только
функции overflow() и underflow() требует своей реализации для каждого
алгоритма буферизации, например:

     class filebuf : public streambuf {
     protected:
         int  fd;            // дескриптор файла
         char opened;        // признак открытия файла
     public:
         filebuf() { opened = 0; }
         filebuf(int nfd, char* p, int l)
             : streambuf(p,l) { /* ... */ }
         ~filebuf() { close(); }

         int overflow(int c=EOF);
         int underflow();

         filebuf* open(char *name, ios::open_mode om);
         int close() { /* ... */ }
         //...
     };
     int filebuf::underflow()    // заполнить буфер из "fd"
     {
         if (!opened || allocate()==EOF) return EOF;

         int count = read(fd, base, eptr-base);
         if (count < 1) return EOF;

         gptr = base;
         pptr = base + count;
         return *gptr & 0377; // &0377 предотвращает размножение знака
      }

За дальнейшими подробностями обратитесь к руководству по реализации
класса streambuf.

        10.6 Ввод-вывод в С

Поскольку текст программ на С и на С++ часто путают, то путают иногда
и потоковый ввод-вывод С++ и функции ввода-вывода семейства  printf для
языка С. Далее, т.к. С-функции можно вызывать из программы на С++, то
многие предпочитают использовать более знакомые функции ввода-вывода С.
        По этой причине здесь будет дана основа функций ввода-вывода С.
Обычно операции ввода-вывода на С и на С++ могут идти по очереди на
уровне строк. Перемешивание их на уровне посимвольного ввода-вывода
возможно для некоторых реализаций, но такая программа может быть
непереносимой. Некоторые реализации потоковой библиотеки С++ при допущении
ввода-вывода на С требуют вызова статической функции-члена
ios::sync_with_stdio().
         В общем, потоковые функции вывода имеют перед стандартной
функцией С printf() то преимущество, что потоковые функции обладают
определенной типовой надежностью и единообразно определяют вывод
объектов предопределенного и пользовательского типов.
     Основная функция вывода С есть

        int printf(const char* format, ...)

и она выводит произвольную последовательность параметров в формате,
задаваемом строкой форматирования format. Строка форматирования состоит
из объектов двух типов: простые символы, которые просто копируются в
выходной поток, и спецификации преобразований, каждая из которых
преобразует и печатает очередной параметр.  Каждая спецификация
преобразования начинается с символа %, например

        printf("there were %d members present.",no_of_members);

Здесь %d указывает, что no_of_members следует считать целым и печатать
как соответствующую последовательность десятичных цифр. Если
no_of_members==127, то будет напечатано

       there were 127 members present.

    Набор спецификаций преобразований достаточно большой и обеспечивает
большую гибкость печати. За символом % может следовать:
- необязательный знак минус, задающий выравнивание влево в указанном
  поле для преобразованного значения;
d необязательная строка цифр,  задающая ширину поля; если в
  преобразованном значении меньше символов, чем ширина строки, то оно
  дополнится до ширины поля пробелами слева (или справа, если дана
  спецификация выравнивания влево); если строка ширины поля начинается
  с нуля, то дополнение будет проводится нулями, а не пробелами;
. необязательный символ точка служит для отделения ширины поля от
  последующей строки цифр;
d необязательная строка цифр, задающая точность, которая определяет
  число цифр после десятичной точки для значений в спецификациях
  e или f, или же задает максимальное число печатаемых символов
  строки;
* для задания ширины поля или точности может использоваться * вместо
  строки цифр. В этом случае должен быть параметр целого типа, который
  содержит значение ширины поля или точности;
h необязательный символ h указывает, что последующая спецификация d,
  o, x или u относится к параметру типа короткое целое;
l необязательный символ l указывает, что последующая спецификация d,
  o, x или u относится к параметру типа длинное целое;
% обозначает, что нужно напечатать сам символ %; параметр не нужен;
c символ, указывающий тип требуемого преобразования. Символы
  преобразования и их смысл следующие:
      d Целый параметр выдается в десятичной записи;
      o Целый параметр выдается в восьмеричной записи;
      x Целый параметр выдается в шестнадцатеричной записи;
      f Вещественный или с двойной точностью параметр выдается в
        десятичной записи  вида [-]ddd.ddd, где число цифр после
        точки равно спецификации точности для параметра. Если точность
        не задана, печатается шесть цифр; если явно задана точность 0,
        точка и цифры после нее не печатаются;
      e Вещественный или с двойной точностью параметр выдается в
        десятичной записи вида [-]d.ddde+dd; здесь одна цифра перед
        точкой, а число цифр после точки равно спецификации точности
        для параметра; если она не задана печатается шесть цифр;
      g Вещественный или с двойной точностью параметр печатается по той
        спецификации d, f или e, которая дает большую точность при
        меньшей ширине поля;
      c Символьный параметр печатается. Нулевые символы игнорируются;
      s Параметр считается строкой (символьный указатель), и печатаются
        символы из строки до нулевого символа или до достижения числа
        символов, равного спецификации точности; но, если точность
        равна 0 или не указана, печатаются все символы до нулевого;
      p Параметр считается указателем и его вид на печати зависит от
        реализации;
      u Беззнаковый целый параметр печатается в десятичной записи.
Несуществующее поле или поле с шириной, меньшей реальной, приведет
к усечению поля. Дополнение пробелами происходит, если только
спецификация ширины поля больше реальной ширины.
Ниже приведен более сложный пример:

     char* src_file_name;
     int line;
     char* line_format = "\n#line %d \"%s\"\n";
     main()
     {
        line = 13;
        src_file_name = "C++/main.c";

        printf("int a;\n");
        printf(line_format,line,src_file_name);
        printf("int b;\n");
     }

в котором печатается

      int a;

      #line 13 "C++/main.c"
      int b;

      Использование printf() ненадежно в том смысле, что нет никакого
контроля типов. Так, ниже приведен известный способ получения
неожиданного результата - печати мусорного значения или чего похуже:

      char x;
      // ...
      printf("bad input char: %s",x);

Однако, эти функции обеспечивают большую гибкость и знакомы
программирующим на С.
      Как обычно, getchar() позволяет знакомым способом читать символы из
входного потока:

      int i;:
      while ((i=getchar())!=EOF) { // символьный ввод C
         // используем i
      }

Обратите внимание: чтобы было законным сравнение с величиной EOF типа
int при проверке на конец файла, результат getchar() надо помещать в
переменную типа int, а не char.
    За подробностями о вводе-выводе на С отсылаем к вашему руководству
по С или книге Кернигана и Ритчи "Язык программирования С".

        10.7 Упражнения

1. (*1.5) Читая файл вещественных чисел, составлять из пар прочитанных
   чисел комплексные числа, записать комплексные числа.
2. (*1.5) Определить тип name_and_address (тип_и_адрес). Определить для
   него << и >>. Написать программу копирования объектов потока
   name_and_address.
3. (*2) Разработать несколько функций для запроса и чтения данных
   разных типов. Предложения: целое, вещественное число, имя файла,
   почтовый адрес, дата, личная информация, и т.п. Попытайтесь сделать
   их устойчивыми к ошибкам.
4. (*1.5) Напишите программу, которая печатает: (1) строчные буквы,
   (2) все буквы, (3) все буквы и цифры, (4) все символы, входящие в
   идентификатор в вашей версии С++, (5) все знаки пунктуации,
   (6) целые значения всех управляющих символов, (7) все обобщенные
   пробелы, (8) целые значения всех обобщенных пробелов, и, наконец,
   (9) все изображаемые символы.
5. (*4) Реализуйте стандартную библиотеку ввода-вывода С (<stdio.h>)
   с помощью стандартной библиотеки ввода-вывода С++ (<iostream.h>).
6. (*4) Реализуйте стандартную библиотеку ввода-вывода С++
   (<iostream.h>) с помощью стандартной библиотеки ввода-вывода С
   (<stdio.h>).
7. (*4) Реализуйте библиотеки С и С++ так, чтобы их можно было
   использовать одновременно.
8. (*2) Реализуйте класс, для которого операция [] перегружена так,
   чтобы обеспечить произвольное чтение символов из файла.
9. (*3) Повторите упражнение 8, но добейтесь, чтобы операция [] была
   применима для чтения и для записи. Подсказка: пусть [] возвращает
   объект "дескриптор типа", для которого присваивание означает:
   присвоить через дескриптор файлу, а неявное приведение к типу char
   означает чтение файла по дескриптору.
10.(*2) Повторите упражнение 9, позволяя операции [] индексировать
   объекты произвольных типов, а не только символы.
11.(*3.5) Продумайте  и реализуйте операцию форматного ввода.
   Используйте для задания формата строку спецификаций как в printf().
   Должна быть возможность  попыток применения нескольких спецификаций для
   одного ввода, чтобы найти требуемый формат. Класс форматного ввода
   должен быть производным класса istream.
12.(*4) Придумайте (и реализуйте) лучшие форматы ввода.
13.(**2) Определите для вывода манипулятор based с двумя параметрами:
   система счисления и целое значение, и печатайте целое в
   представлении, определяемом системой счисления. Например, based(2,9)
   напечатает 1001.
14.(**2) Напишите "миниатюрную" систему ввода-вывода, которая реализует
   классы istream, ostream, ifstream, ofstream и предоставляет функции,
   такие как operator<<() и operator>>() для целых, и операции, такие
   как open() и close() для файлов. Используйте исключительные
   ситуации, а не переменные состояния, для сообщения об ошибках.
15.(**2) Напишите манипулятор, который включает и отключает эхо
   символа.




         * ПРОЕКТИРОВАНИЕ  И РАЗВИТИЕ

            "Серебряной пули не существует."
                        - Ф. Брукс

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

        11.1 Введение

Создание любой нетривиальной программной системы - сложная и часто
выматывающая задача. Даже для отдельного программиста собственно запись
операторов программы есть только часть всей работы. Обычно анализ всей
задачи, проектирование программы в целом, документация, тестирование,
сопровождение и управление всем этим затмевает задачу написания и
отладки отдельных частей программы. Конечно, можно все эти виды
деятельности обозначить  как  "программирование" и затем вполне
обоснованно утверждать: "Я не проектирую, я только программирую".
Но как бы не назывались отдельные виды деятельности, бывает иногда важно
сосредоточиться на них по отдельности, так же как иногда бывает важно
рассмотреть весь процесс в целом. Стремясь поскорее довести систему
до поставки, нельзя упускать из вида ни детали, ни картину в целом,
хотя довольно часто происходит именно это.
Эта глава сосредоточена на тех частях процесса развития программы,
которые не связаны с написанием и отладкой отдельных программных
фрагментов. Обсуждение здесь менее точное и детальное, чем во всех
остальных частях книги, где рассматриваются конкретные черты языка
или определенные приемы программирования. Это неизбежно, поскольку нет
готовых рецептов создания хороших программ. Детальные рецепты "как"
могут существовать только для определенных, хорошо разработанных областей
применения, но не для достаточно широких областей приложения. В
программировании не существует заменителей разума, опыта и вкуса.
Следовательно, в этой главе вы найдете только общие рекомендации,
альтернативные подходы и осторожные выводы.
     Сложность данной тематики связана с абстрактной природой программ
и тем фактом, что приемы, применимые для небольших проектов (скажем,
программа в 10000 строк, созданная одним или двумя людьми), не
распространяются на средние или большие проекты. По этой причине иногда
мы приводим  примеры из менее абстрактных инженерных дисциплин, а не
только из программирования. Не преминем напомнить, что "доказательство по
аналогии" является мошенничеством, и аналогии служат здесь только в
качестве примера. Понятия проектирования, формулируемые
с помощью определенных конструкций С++, и поясняемые примерами, мы
будем обсуждать в главах 12 и 13. Предложенные в этой главе рекомендации,
отражаются как в самом языке С++, так и в решении конкретных программных
задач по всей книге.
     Снова напомним, что в силу чрезвычайного разнообразия областей
применения, программистов и среды, в которой развивается программная
система, нельзя ожидать, что каждый вывод, сделанный здесь, будет
прямо применим для вашей задачи. Эти выводы применимы
во многих самых разных случаях, но их нельзя считать универсальными
законами. Смотрите на них со здоровой долей скептицизма.
     Язык С++ можно просто использовать как лучший вариант С. Однако,
поступая так, мы не используем наиболее мощные возможности С++ и
определенные приемы программирования на нем, так что реализуем лишь
малую долю потенциальных достоинств С++. В этой главе излагается такой
подход к проектированию, который позволяет полностью использовать
возможности абстрактных данных и средства объектного программирования С++.
Такой подход обычно называют объектно-ориентированным проектированием.
В главе 12 обсуждаются основные приемы программирования на С++, там же
содержится предостережение от сомнительных идей, что есть только один
"правильный" способ использования С++, и что для получения
максимального выигрыша следует всякое средство С++
применять в любой программе ($$12.1).
      Укажем некоторые основные принципы, рассматриваемые в этой главе:
   - из всех вопросов, связанных с процессом развития программного
     обеспечения, самый важный - четко сознавать, что собственно вы
     пытаетесь создать.
   - Успешный процесс развития программного обеспечения - это дли-
     тельный процесс.
   - Системы, которые мы создаем, стремятся к пределу сложности
     по отношению как к самим создателям, так и используемым средствам.
   - Эксперимент является необходимой частью проекта для разработки всех
     нетривиальных программных систем.
   - Проектирование и программирование - это итеративные процессы.
   - Различные стадии проекта программного обеспечения, такие как:
     проектирование, программирование и тестирование - невозможно строго
     разделить.
   - Проектирование и программирование нельзя рассматривать в отрыве от
     вопросов управления этими видами деятельности.
Недооценить любой из этих принципов очень легко, но обычно накладно.
В то же время трудно воплотить эти абстрактные идеи на практике.
Здесь необходим определенный опыт. Подобно построению лодки, езде на
велосипеде или программированию проектирование - это искусство, которым
нельзя овладеть только с помощью теоретических занятий.
     Может быть все эти емкие принципы можно сжать в один:
проектирование и программирование - виды человеческой деятельности;
забудь про это - и все пропало.
Слишком часто мы забываем про это и рассматриваем процесс развития
программного обеспечения просто как "последовательность хорошо
определенных шагов, на каждом из которых по заданным правилам
производятся некоторые действия над входными данными, чтобы получить
требуемый результат". Сам стиль предыдущего предложения выдает
присутствие человеческой природы!
Эта глава относится к проектам, которые можно считать честолюбивыми,
если учитывать ресурсы и опыт людей, создающих систему. Похоже, это в
природе как индивидуума, так и организации - браться за проекты на
пределе своих возможностей. Если задача не содержит определенный вызов,
нет смысла уделять особое внимание ее проектированию. Такие задачи
решаются в рамках уже устоявшейся структуры, которую не следует разрушать.
Только если замахиваются на что-то амбициозное, появляется потребность
в новых, более мощных средствах и приемах. Кроме того, существует
тенденция у тех, кто "знает как делать", перепоручать проект новичкам,
которые не имеют таких знаний.
     Не существует "единственного правильного способа" для
проектирования и создания всей системы. Я бы считал веру в "единственный
правильный способ" детской болезнью, если бы этой болезнью слишком
часто не заболевали и опытные программисты. Напомним еще раз: только
по той причине, что прием успешно использовался в течение года для
одного проекта, не следует, что он без всяких изменений окажется
столь же полезен для другого человека или другой задачи. Всегда важно
не иметь предубеждений.
  Убеждение в том, что нет единственно верного решения, пронизывает
весь проект языка С++, и, в основном, по этой причине в первом издании
книги не было раздела, посвященного проектированию: я не хотел, чтобы
его рассматривали как "манифест" моих личных симпатий. По этой же
причине здесь, как и в главах 12 и 13, нет четко определенного взгляда на
процесс развития программного обеспечения, скорее здесь просто дается
обсуждение определенного круга, часто возникающих, вопросов и
предлагаются некоторые решения, оказавшиеся полезными в определенных
условиях.
      За этим введением следует краткое обсуждение целей и средств
развития программного обеспечения в $$11.2, а дальше глава распадается
на две основных части:
- $$11.3 содержит описание процесса развития  программного обеспечения.
- $$11.4 содержит некоторые практические рекомендации по организации
  этого процесса.
Взаимосвязь между проектированием и языком программирования обсуждается
в главе 12, а глава 13 посвящена вопросам проектирования библиотек для
С++.
   Очевидно, большая часть рассуждений относится к программным проектам
большого объема. Читатели, которые не участвуют в таких разработках,
могут сидеть спокойно и радоваться, что все эти ужасы  их миновали,
или же они могут выбрать вопросы, касающиеся только их интересов. Нет
нижней границы размера программы, начиная с которой имеет смысл заняться
проектированием прежде, чем начать писать программу. Однако все-таки есть нижняя
граница, начиная с которой можно использовать какие-либо методы
проектирования. Вопросы, связанные с размером, обсуждаются в $$11.4.2.
    Труднее всего в программных проектах бороться с их сложностью.
Есть только один общий способ борьбы со сложностью: разделяй и
властвуй. Если задачу удалось разделить на две подзадачи, которые можно
решать в отдельности, то можно считать ее решенной за счет разделения
более, чем наполовину. Этот простой принцип применим для удивительно
большого числа ситуаций. В частности, использование модулей или классов
при разработке программных систем позволяет разбить программу на две
части: часть реализации и часть, открытую пользователю - которые
связаны между собой (в идеале) вполне определенным интерфейсом. Это
основной, внутренне присущий программированию, принцип борьбы со
сложностью.
Подобно этому и процесс проектирования программы можно разбить на
отдельные виды деятельности с четко определенным (в идеале)
взаимодействием между людьми, участвующими в них. Это основной,
внутренне присущий проектированию, принцип борьбы со сложностью и
подход к управлению людьми,занятыми в проекте.
  В обоих случаях выделение частей и определение интерфейса между
частями - это то место, где требуется максимум опыта и чутья. Такое
выделение не является чисто механическим процессом, обычно оно требует
проницательности, которая может появиться только в  результате  доско-
нального понимания   системы  на  различных  уровнях  абстракции  (см.
$$11.3.3, $$12.2.1 и $$13.3). Близорукий взгляд на программу или на
процесс разработки программного обеспечения часто приводит к дефектной
системе. Отметим, что как программы, так и программистов разделить
просто. Труднее достигнуть эффективного взаимодействия между участниками
по обе стороны границы, не нарушая ее и не делая взаимодействие слишком
жестким.
   Здесь предложен определенный подход к проектированию, а не полное
формальное описание метода проектирования. Такое описание выходит за
предметную область книги. Подход, предложенный здесь, можно применять
с различной степенью формализации, и он может служить базой для различных
формальных спецификаций. В тоже время нельзя считать эту главу
рефератом, и здесь не делается попытка рассмотреть каждую тему,
относящуюся к процессу разработки программ или изложить каждую точку
зрения. Это тоже выходит за предметную область книги. Реферат по этой
тематике можно найти в [2]. В этой книге используется достаточно
общая и традиционная терминология. Самые "интересные" термины, как:
проектирование, прототип, программист - имеют в литературе несколько
определений, часто противоречащих друг другу, поэтому предостерегаем вас
от того, чтобы, исходя из принятых в вашем окружении определений терминов,
вы не вынесли из книги то, на что автор совершенно не рассчитывал.

        11.2 Цели и средства

Цель программирования - создать продукт, удовлетворяющий пользователя.
Важнейшим средством для достижении этой цели является создание
программы с ясной внутренней структурой и воспитание коллектива
программистов и разработчиков, имеющих достаточный опыт и мотивацию,
чтобы быстро и эффективно реагировать на все изменения.
   Почему это так? Ведь внутрення структура программы и процесс, с
помощью которого она получена, в идеале никак не касаются конечного
пользователя. Более того, если конечный пользователь почему-то
интересуется тем, как написана программа, то что-то с этой программой
не так. Почему, несмотря на это, так важны структура программы и люди,
ее создавшие?  В  конце  концов  конечный пользователь ничего об этом
не должен знать.
   Ясная внутренняя структура программы облегчает:
   - тестирование,
   - переносимость,
   - сопровождение,
   - расширение,
   - реорганизацию и
   - понимание.
Главное здесь в том, что любая удачная большая программа имеет
долгую жизнь, в течение которой над ней работают
поколения программистов и разработчиков, она переносится на новую
машину, приспосабливается к непредусмотренным требованиям и несколько
раз перестраивается. Во все время жизни необходимо в приемлемое время и
с допустимым числом ошибок выдавать версии программы. Не планировать все
это - все равно, что запланировать неудачу.
    Отметим, что, хотя в идеальном случае случае пользователи не
должны знать внутреннюю структуру системы, на практике они обычно
хотят ее знать. Например, пользователь может желать познакомиться в
деталях с разработкой системы с целью научиться контролировать
возможности и надежность системы на случай переделок и расширений.
Если рассматриваемый программный продукт есть не полная система, а набор
библиотек для получения программных систем, то пользователь захочет
узнать побольше "деталей", чтобы они служили источником идей и
помогали лучше использовать библиотеку.
    Нужно уметь очень точно определить объем проектирования программы.
Недостаточный объем приводит к бесконечному срезанию острых углов
("побыстрее передадим систему, а ошибку устраним в следующей версии").
Избыточный объем приводит к усложненному описанию системы, в котором
существенное теряется в формальностях, в результате чего при
реорганизации программы получение работающей версии затягивается ("новая
структура намного лучше старой, пользователь согласен ждать ради нее").
К тому же возникают такие потребности в ресурсах, которые непозволительны
для большинства потенциальных пользователей. Выбор объема
проектирования - самый трудный момент в разработке, именно здесь
проявляется талант и опыт. Выбор трудно сделать и для одного программиста
или разработчика, но он еще труднее для больших задач, где занято
много людей разного уровня квалификации.
    Организация должна создавать программный продукт и сопровождать
его, несмотря на изменения в штате, в направлении работы или в
управляющей структуре. Распространенный способ решения этих проблем
заключался в попытке сведения процесса создания системы к нескольким
относительно простым задачам, укладывающимся в жесткую структуру.
Например, создать группу легко обучаемых (дешевых) и взаимозаменяемых
программистов низкого уровня ("кодировщиков") и группу не таких
дешевых, но взаимозаменяемых (а значит также не уникальных)
разработчиков. Считается, что кодировщики не принимают решений по
проектированию, а разработчики не утруждают  себя  "грязными"
подробностями кодирования. Обычно такой подход приводит к неудаче, а
где он срабатывает, получается слишком громоздкая система с плохими
характеристиками.
     Недостатки такого подхода состоят в следующем:
  - слабое взаимодействие между программистами и разработчиками
   приводит к неэффективности, промедлению, упущенным возможностям и
   повторению ошибок из-за плохого учета и отсутствия обмена опытом;
 - сужение области творчества разработчиков приводит
   к слабому профессиональному росту, безынициативности, небрежности и
   большой текучести кадров.
По сути, подобные системы - это бесполезная трата редких человеческих
талантов. Создание структуры, в рамках которой люди могут найти
применение разным талантам, овладеть новым родом деятельности и
участвовать в творческой работе - это не только благородное дело, но
и практичное, коммерчески выгодное предприятие.
  С другой стороны, нельзя создать систему, представить документацию
по ней и бесконечно ее сопровождать без некоторой жесткой организационной
структуры. Для чисто новаторского проекта хорошо начать с того, что
просто найти лучших специалистов и позволить им решать задачу в
соответствии с их идеями.  Но по мере развития проекта  требуется  все
больше планирования,  специализации и строго определенного взаимодействия
между занятыми в нем людьми. Под строго определенным понимается не
математическая или автоматически верифицируемая запись (хотя это
безусловно хорошо там, где возможно и применимо), а скорее набор
указаний по записи, именованию, документации, тестированию и т.п.
Но и здесь необходимо чувство меры. Слишком жесткая структура может
мешать росту и затруднять совершенствование. Здесь подвергается
проверке талант и опыт менеджера. Для отдельного работника аналогичная
проблема сводится к определению, где нужно проявить смекалку, а где
действовать по рецептам.
   Можно рекомендовать планировать не на период до выдачи следующей
версии системы, а на более долгий срок. Строить планы только до
выпуска очередной версии - значит планировать неудачу. Нужно иметь
организацию и стратегию развития программного обеспечения, которые
нацелены на создание и поддержание многих версий разных систем, т.е.
нужно многократное планирование успеха.
    Цель проектирования в выработке ясной и относительно простой
внутренней структуры программы, называемой иногда архитектурой, иными
словами каркаса, в который укладываются отдельные программные фрагменты,
и который помогает написанию этих фрагментов.
   Проект - конечный результат процесса проектирования (если только
бывает конечный продукт у итеративного процесса). Он является
средоточием взаимодействий между разработчиком и программистом и
между программистами. Здесь необходимо соблюсти чувство меры. Если я,
как отдельный программист, проектирую небольшую программу, которую
собираюсь написать завтра, то точность и полнота описания проекта
может свестись к нескольким каракулям на обратной стороне конверта.
На другом полюсе находится система, над которой работают сотни
программистов и разработчиков, и здесь могут потребоваться тома
тщательно составленных спецификаций проекта на формальном или
полуформальном языке. Определение нужной степени точности, детализации
и формальности проектирования является уже само по себе нетривиальной
технической и административной задачей.
   Далее будет предполагаться, что проект системы записывается
как ряд определений классов (в которых частные описания опущены
как лишние детали) и взаимоотношений между ними. Это упрощение, т.к.
конкретный проект может учитывать: вопросы параллельности, использование
глобального пространства имен, использование глобальных функций и
данных, построение программы для минимизации перетрансляции,
устойчивость, многомашинный режим и т.п. Но при обсуждении на данном
уровне детализации без упрощения не обойтись, а классы в контексте С++
являются ключевым понятием проектирования. Некоторые из указанных
вопросов будут обсуждаться ниже, а те, которые прямо затрагивают
проектирование библиотек С++, будут рассмотрены в главе 13. Более
подробное обсуждение и примеры определенных методов объектно-
ориентированного проектирования содержатся в [2].
    Мы сознательно не проводили четкого разделения анализа и
проектирования, поскольку обсуждение их различий выходит за рамки этой
книги, и оно зависит от применяемых методов проектирования. Главное в том,
чтобы выбрать метод анализа, подходящий для метода проектирования, и
выбрать метод проектирования, подходящий для стиля программирования
и используемого языка.

        11.3 Процесс развития

Процесс развития программного обеспечения - это итеративный и
расширяющийся процесс. По мере развития каждая стадия повторяется
многократно, и при всяком возврате на некоторую стадию процесса уточняется
конечный продукт, получаемый на этой стадии. В общем случае процесс
не имеет ни начала, ни конца, поскольку, проектируя и реализуя систему,
вы начинаете, используя как базу другие проекты, библиотеки и прикладные
системы, в конце работы после вас остается описание проекта и программа,
которые другие могут уточнять, модифицировать, расширять и переносить.
Естественно конкретный проект имеет определенное начало и конец, и
важно (хотя часто удивительно трудно) четко и строго ограничить время
и область действия проекта. Но заявление, что вы начинаете с "чистого
листа", может привести к серьезным проблемам для вас, также как и позиция,
что после передачи окончательной версии - хоть потоп, вызовет
серьезные проблемы для ваших последователей (или для вас в новой
роли).
    Из этого вытекает, что следующие разделы можно читать в любом
порядке, поскольку вопросы проектирования и реализации могут в
реальном проекте переплетаться почти произвольно. Именно, "проект"
почти всегда подвергается перепроектированию на основе предыдущего
проекта, определенного опыта реализации, ограничений, накладываемых
сроками, мастерством работников, вопросами совместимости и т.п.
Здесь основная трудность для менеджера или разработчика или
программиста в том, чтобы создать такой порядок в этом процессе,
который не препятствует усовершенствованиям и не запрещает повторные
проходы, необходимые для успешного развития.
   У процесса развития три стадии:
 - Анализ: определение области задачи.
 - Проектирование: создание общей структуры системы.
 - Реализация: программирование и тестирование.
Не забудьте об итеративной природе этих процессов (неспроста стадии
не были пронумерованы), и заметьте, что никакие важные аспекты процесса
развития программы не выделяются в отдельные стадии, поскольку они
должны допускать:
 - Экспериментирование.
 - Тестирование.
 - Анализ проектирования и реализации.
 - Документирование.
 - Сопровождение.
 Сопровождение программного обеспечения рассматривается просто как
 еще несколько проходов по стадиям процесса развития (см. также
$$11.3.6).
   Очень важно, чтобы анализ, проектирование и реализация не были
слишком оторваны друг от друга, и чтобы люди, принимающие в них
участие, были одного уровня квалификации для налаживания эффективных
контактов.
В больших проектах слишком часто бывает иначе. В идеале, в процессе
развития проекта работники должны сами переходить с одной стадии на
другую: лучший способ передачи тонкой информации - это использовать
голову работника. К сожалению, в организациях часто устанавливают
барьеры для таких переходов, например, у разработчика может быть
более высокий статус и (или) более высокий оклад, чем у "простого"
программиста. Не принято, чтобы сотрудники ходили по отделам с целью
набраться опыта и знаний, но пусть, по крайней мере, будут
регулярными собеседования сотрудников, занятых на разных стадиях проекта.
   Для средних и малых проектов обычно не делают различия между
анализом и проектированием - эти стадии сливаются в одну. Для малых
проектов также не разделяют проектирование и программирование.
Конечно, тем самым решается проблема взаимодействия. Для данного
проекта важно найти подходящую степень формализации и выдержать
нужную степень разделения между стадиями ($$11.4.2). Нет единственно
верного способа для этого.
   Приведенная здесь модель процесса развития программного обеспечения
радикально отличается от традиционной модели "каскад" (waterfall).
В последней процесс развития протекает линейно от стадии анализа до
стадии тестирования. Основной недостаток модели каскад тот, что в ней
информация движется только в одном направлении. Если выявлена
проблема "ниже по течению", то возникает сильное методологическое
и организационное давление, чтобы решить проблему на данном уровне,
не затрагивая предыдущих стадий процесса. Отсутствие повторных
проходов приводит к дефектному проекту, а в результате локального
устранения проблем получается искаженная реализация. В тех
неизбежных случаях, когда информация должна быть передана назад к
источнику ее получения и вызвать изменения в проекте, мы получим
лишь слабое "колыхание" на всех уровнях системы, стремящейся подавить
внесенное изменение, а значит система плохо приспособлена к
изменениям. Аргумент в пользу "никаких изменений" или "только локальные
изменения" часто сводится к тому, что один отдел не хочет
перекладывать большую работу на другой отдел "ради их же блага".
Часто бывает так, что ко времени, когда ошибка уже найдена, исписано
столько бумаги относительно ошибочного решения, что усилия,
нужные на исправление документации, затмевают усилия для исправления
самой программы. Таким образом, бумажная работа может стать главной
проблемой процесса создания системы. Конечно, такие проблемы могут быть
и возникают в процессе развития больших систем. В конце концов,
определенная работа с бумагами необходима. Но выбор линейной модели
развития (каскад) многократно увеличивает вероятность, что эта
проблема выйдет из-под контроля.
Недостаток модели каскад в отсутствии повторных проходов и
неспособности реагировать на изменения. Опасность предлагаемой здесь
итеративной модели состоит в искушении заменить размышление и
реальное развитие на последовательность бесконечных изменений.
Тот и другой недостатки легче указать, чем устранить, и для того,
кто организует работу, легко принять простую активность за реальный
прогресс.
    Вы можете уделять пристальное внимание деталям, использовать
разумные приемы управления, развитую технологию, но ничто не спасет
вас, если нет ясного понимания того, что вы пытаетесь создать. Больше
всего проектов проваливалось именно из-за отсутствия хорошо
сформулированных реалистичных целей, а не по какой-либо иной причине.
Что бы вы не делали и чем бы не занимались, надо ясно представлять
имеющиеся у вас средства, ставить достижимые цели и ориентиры и не
искать технических решений социологических проблем. С другой стороны,
надо применять только адекватную технологию, даже если она потребует
затрат,- люди работают лучше, имея адекватные средства и приемлемую
среду. Не заблуждайтесь, думая, что легко выполнить эти рекомендации.

        11.3.1 Цикл развития

Процесс развития системы - это итеративная деятельность. Основной
цикл сводится к повторяемым в следующей последовательности шагам:
 [1] Создать общее описание проекта.
 [2] Выделить стандартные компоненты.
     [a] Подогнать компоненты под данный проект.
 [3] Создать новые стандартные компоненты.
     [a] Подогнать компоненты под данный проект.
 [4] Составить уточненное описание проекта.
В качестве примера рассмотрим автомобильный завод. Проект должен
начинаться с самого общего описания новой машины. Этот первый шаг
базируется на некотором анализе и описании машины в самых общих
терминах, которые скорее относятся к предполагаемому использованию,
чем к характеристикам желаемых возможностей машины. Часто самой
трудной частью проекта бывает выбор желаемых возможностей, или,
точнее, определение относительно простого критерия выбора желаемых
возможностей. Удача здесь, как правило, является
результатом работы отдельного проницательного человека и часто
называется предвидением. Слишком типично как раз отсутствие
ясных целей, что приводит к неуверенно развивающимся или просто
проваливающимся проектам.
    Итак, допустим необходимо создать машину среднего размера с
четырьмя дверцами и достаточно мощным мотором. Очевидно, что
на первом этапе проекта не следует начинать проектирование машины
(и всех ее компонентов) с нуля. Хотя программист или разработчик
программного обеспечения в подобных обстоятельствах поступит именно
так.
     На первом этапе надо выяснить, какие компоненты доступны на
вашем собственном складе и какие можно получить от надежных
поставщиков. Найденные таким образом компоненты не обязательно
в точности подойдут для новой машины. Всегда требуется подгонка
компонентов. Может быть даже потребуется изменить характеристики
"следующей версии" выбранных компонентов, чтобы сделать их
пригодными для проекта. Например, может существовать вполне пригодный
мотор, вырабатывающий немного меньшую мощность.Тогда
или вы, или поставщик мотора должны предложить, не изменяя общего
описания проекта, в качестве компенсации дополнительный
зарядный генератор.  Заметим, что сделать это,"не изменяя общего описания
проекта", маловероятно, если только само описание не приспособлено
к определенной подгонке. Обычно подобная
подгонка требует кооперации между вами и поставщиком моторов.
Сходные вопросы возникают и у программиста или разработчика
программного обеспечения. Здесь подгонку обычно облегчает эффективное
использование производных классов. Но не рассчитывайте провести
произвольные расширения в проекте без определенного предвидения
или кооперации с создателем таких классов.
    Когда исчерпается набор подходящих стандартных компонентов,
проектировщик машины не спешит заняться проектированием новых
оптимальных компонентов для своей машины. Это было бы слишком
расточительно. Допустим, что не нашлось подходящего блока
кондиционирования воздуха, зато есть свободное пространство, имеющее
форму буквы L, в моторном отсеке. Возможно решение разработать
блок кондиционирования указанной формы. Но вероятность того, что
блок подобной странной формы будет использоваться в машинах другого
типа (даже после значительной подгонки), крайне низка. Это означает,
что наш проектировщик машины не сможет разделить затраты на
производство такого блока с создателями машин другого типа, а значит
время жизни этого блока коротко. Поэтому стоит спроектировать блок,
который найдет более широкое применение, т.е. разработать
разумный проект блока, более приспособленный для подгонки, чем наше
L-образное чудище. Возможно, это потребует больших усилий, и даже
придется для приспособления более универсального блока изменить
общее описание проекта машины. Поскольку новый блок разрабатывался
для более общего применения, чем наше L-образное чудище,
предположительно, для него потребуется некоторая подгонка, чтобы
полностью удовлетворить наши пересмотренные запросы.
Подобная же альтернатива возникает и у программиста или разработчика
программного обеспечения: вместо того, чтобы создать программу,
привязанную к конкретному проекту, разработчик может спроектировать
новую достаточно универсальную программу, которая будет иметь
хорошие шансы стать стандартной в определенной области.
     Наконец, когда мы прошлись по всем стандартным компонентам,
составляется "окончательное" общее описание проекта. Несколько
специально разработанных средств указываются как возможные. Вероятно,
в следующем году придется для новой модели повторить наши шаги,
и как раз эти специальные средства придется переделать или выбросить.
Как ни печально, но опыт традиционно проектировавшихся программ
показывает, что лишь несколько частей системы можно выделить в
отдельные компоненты и лишь несколько из них пригодны вне
данного проекта.
     Мы не пытаемся утверждать, что все разработчики машин
действуют столь разумно, как в приведенном примере, а разработчики
программ совершают все указанные ошибки. Утверждается, что указанная
методика разработки машин применима и для программного обеспечения.
Так, в этой и следующей главах даны приемы использования ее для С++.
Тем не менее можно сказать, что сама природа программирования
способствует совершению указанных ошибок ($$12.2.1 и $$12.2.5).
В разделе 11.4.3 опровергается профессиональное предубеждение против
использования описанной здесь модели проектирования.
 Заметим, что модель развития программного обеспечения хорошо
применима только в расчете на большие сроки. Если ваш горизонт
сужается до времени выдачи очередной версии, нет смысла создавать
и поддерживать функционирование стандартных компонентов. Это
просто приведет к излишним накладным расходам. Наша модель
рассчитана на организации со временем жизни, за которое проходит
несколько проектов, и с размерами, которые позволяют нести
дополнительные расходы и на средства проектирования, программирования,
и на сопровождение проектов, и на повышение квалификации разработчиков,
программистов и менеджеров. Фактически это эскиз некоторой фабрики по
производству программ. Как ни удивительно, она только масштабом
отличается от действий лучших программистов, которые для повышения своей
производительности в течении лет накапливали запас приемов и методов
проектирования, создавали инструменты и библиотеки. Похоже, что
большинство организаций просто не умеет воспользоваться достижениями
лучших сотрудников, как из-за отсутствия предвидения, так и по
неспособности применить эти достижения в достаточно широком
объеме.
    Все-таки неразумно требовать, чтобы "стандартные компоненты"
были стандартными универсально. Существует лишь малое число
международных стандартных библиотек, а в своем большинстве компоненты
окажутся стандартными только в пределах страны, отрасли, компании,
производственной цепочки, отдела или области приложения и т.д.
Просто мир слишком велик, чтобы универсальный стандарт
всех компонентов и средств был реальной или желанной целью проекта.


        11.3.2 Цели проектирования

Каковы самые общие цели проектирования? Конечно, простота, но в чем
критерий простоты? Поскольку мы считаем, что проект должен развиваться
во времени, т.е. система будет расширяться, переноситься,
настраиваться и, вообще, изменяться массой способов, которые невозможно
предусмотреть, необходимо стремиться к такой системе проектирования
и реализации, которая была бы простой с учетом, что она будет
меняться многими способами. На самом деле, практично допустить,
что сами требования к системе будут меняться неоднократно за период
от начального проекта до выдачи первой версии системы.
     Вывод таков: система должна проектироваться максимально простой
при условии, что она будет подвергаться серии изменений. Мы должны
проектировать в расчете на изменения, т.е. стремиться к
  - гибкости,
  - расширяемости и
  - переносимости
Лучшее решение - выделить части системы, которые вероятнее всего будут
меняться, в самостоятельные единицы, и предоставить программисту или
разработчику гибкие возможности для модификаций таких единиц. Это
можно сделать, если выделить ключевые для данной задачи понятия
и предоставить класс, отвечающий за всю информацию, связанную с
отдельным понятием (и только с ним). Тогда изменение будет затрагивать
только определенный класс. Естественно, такой идеальный способ
гораздо легче описать, чем воплотить.
   Рассмотрим пример: в задаче моделирования метеорологических
объектов нужно представить дождевое облако. Как это сделать?
У нас нет общего метода изображения облака, поскольку его вид зависит
от внутреннего состояния облака, а оно может быть задано только
самим облаком.
    Первое решение: пусть облако изображает себя само. Оно подходит
для многих ограниченных приложений. Но оно не является достаточно
общим, поскольку существует много способов представления облака:
детальная картина, набросок очертаний, пиктограмма, карта и т.п.
Другими словами, вид облака определяется как им самим, так и его
окружением.
    Второе решение заключается в том, чтобы предоставить самому облаку
для его изображения сведения о его окружении. Оно годится для
большего числа случаев. Однако и это не общее решение. Если мы
предоставляем облаку сведения об его окружении, то нарушаем основной
постулат, который требует, чтобы класс отвечал только за одно
понятие, и каждое понятие воплощалось определенным классом.
Может оказаться невозможным предложить согласованное определение
"окружения облака", поскольку, вообще говоря, как выглядит облако
зависит от самого облака и наблюдателя. Чем представляется облако
мне, сильно зависит от того, как я смотрю на него: невооруженным
глазом, с помощью поляризационного фильтра, с помощью метеорадара и т.д.
Помимо наблюдателя и облака следует учитывать и "общий фон", например,
относительное положение солнца. К дальнейшему усложнению картины
приводит добавление новых объектов типа других облаков, самолетов.
Чтобы сделать задачу разработчика практически неразрешимой, можно
добавить возможность одновременного существования нескольких
наблюдателей.
     Третье решение состоит в том, чтобы облако, а также и другие
объекты, например, самолеты или солнце, сами описывали себя по
отношению к наблюдателю. Такой подход обладает достаточной
общностью, чтобы удовлетворить большинство запросовЬ. Однако,
он может привести к значительному усложнению и большим накладным
расходам при выполнении. Как, например, добиться того, чтобы
наблюдатель понимал описания, произведенные облаком или другими
объектами?

Ь Даже эта модель будет, по всей видимости, не достаточной для таких
  предельных случаев, как графика с высокой степенью разрешимости.
  Я думаю, что для получения очень детальной картины нужен другой
  уровень абстракции.

     Дождевые облака - это не тот объект, который часто встретишь
в программах, но объекты, участвующие в различных операциях ввода
и вывода, встречаются часто. Поэтому можно считать пример с облаком
пригодным для программирования вообще и для разработки библиотек
в частности. Логически схожий пример в С++ представляют манипуляторы,
которые используются для форматирования вывода в потоковом
вводе-выводе ($$10.4.2). Заметим, что третье решение не есть "верное
решение", это просто более общее решение. Разработчик должен
сбалансировать различные требования системы, чтобы найти уровень
общности и абстракции, пригодный для данной задачи в данной области.
Золотое правило: для программы с долгим сроком жизни правильным
будет самый общий уровень абстракции, который вам еще понятен и
который вы можете себе позволить, но не обязательно абсолютно
общий. Обобщение, выходящее за пределы данного проекта и
понятия людей, в нем участвующих, может принести вред, т.е.
привести к задержкам, неприемлемым характеристикам, неуправляемым
проектам и просто к провалу.
     Чтобы использование указанных методов было экономично и
поддавалось управлению, проектирование и управление должно
учитывать повторное использование, о чем говорится в $$11.4.1 и
не следует совсем забывать об эффективности (см. $$11.3.7).

        11.3.3 Шаги проектирования

Рассмотрим проектирование отдельного класса. Обычно это не лучший
метод. Понятия не существуют изолированно, наоборот, понятие
определяется в связи с другими понятиями. Аналогично и класс не
существует изолированно, а определяется совместно с множеством
связанных между собой классов. Это множество часто называют
библиотекой классов или компонентом. Иногда все классы компонента
образуют единую иерархию, иногда это не так (см. $$12.3).
   Множество классов компонента бывают объединены некоторым логическим
условием, иногда это - общий стиль программирования или описания,
иногда - предоставляемый сервис. Компонент является единицей
проектирования, документации, права собственности и,
часто, повторного использования.
Это не означает, что если вы используете один класс компонента, то
должны разбираться во всех и уметь применять все классы компонента или
должны подгружать к вашей программе модули всех классов компонента. В
точности наоборот, обычно стремятся обеспечить, чтобы использование
класса вело к минимуму накладных расходов: как машинных ресурсов,
так и человеческих усилий. Но для использования любого класса
компонента нужно понимать логическое условие, которое его
определяет (можно надеяться, что оно предельно ясно изложено в
документации), понимать соглашения и стиль, примененный в процессе
проектирования и описания компонента, и доступный сервис (если он
есть).
     Итак, перейдем к способам проектирования компонента. Поскольку
часто это непростая задача, имеет смысл разбить ее на шаги и,
сконцентрировавшись на подзадачах, дать полное и последовательное
описание. Обычно нет единственно правильного способа разбиения.
Тем не менее, ниже приводится описание последовательности шагов,
которая пригодилась в нескольких случаях:
  [1] Определить понятие / класс и установить основные связи
      между ними.
  [2] Уточнить определения классов, указав набор операций для
      каждого.
      [a] Провести классификацию операций. В частности уточнить
          необходимость построения, копирования и уничтожения.
      [b] Убедиться в минимальности, полноте и удобстве.
  [3] Уточнить определения классов, указав их зависимость от
      других классов.
      [a] Наследование.
      [b] Использование зависимостей.
  [4] Определить интерфейсы классов.
      [a] Поделить функции на общие и защищенные.
      [b] Определить точный тип операций класса.
Отметим, что это шаги итеративного процесса. Обычно для получения
проекта, который можно уверенно использовать для первичной реализации
или повторной реализации, нужно несколько раз проделать
последовательность шагов. Одним из преимуществ глубокого анализа и
предложенной здесь  абстракции  данных  оказывается относительная
легкость, с которой можно перестроить взаимоотношения классов
даже после программирования каждого класса. Хотя это никогда не
бывает просто.
     Далее следует приступить к реализации классов, а затем
вернуться, чтобы оценить проект, исходя из опыта реализации.
Рассмотрим эти шаги в отдельности.

        11.3.3.1 Шаг 1: определение классов

Определите понятия/классы и установите основные связи между ними.
Главное в хорошем проекте - прямо отразить какое-либо понятие
"реальности", т.е. уловить понятие из области приложения классов,
представить взаимосвязь между классами строго определенным способом,
например, с помощью наследования, и повторить эти действия на
разных уровнях абстракции. Но как мы можем уловить эти понятия?
Как на практике решить, какие нам нужны классы?
     Лучше поискать ответ в самой области приложения, чем рыться
в программистском хранилище абстракций и понятий. Обратитесь к тому,
кто стал экспертом по работе в некогда сделанной системе, а также
к тому, кто стал критиком системы, пришедшей ей на смену. Запомните
выражения того и другого.
    Часто говорят, что существительные играют роль классов и объектов,
используемых в программе, это действительно так. Но это только начало.
Далее, глаголы могут представлять операции над объектами или
обычные (глобальные) функции, вырабатывающие новые значения, исходя
из своих параметров, или даже классы. В качестве примера
можно рассматривать функциональные объекты, описанные в $$10.4.2.
Такие глаголы, как "повторить" или "совершить" (commit) могут быть
представлены итеративным объектом или объектом, представляющим
операцию выполнения программы в базах данных.
Даже прилагательные можно успешно
представлять с помощью классов, например, такие, как "хранимый",
"параллельный", "регистровый", "ограниченный". Это могут быть классы,
которые помогут разработчику или программисту, задав виртуальные
базовые классы, специфицировать и выбрать нужные свойства для
классов, проектируемых позднее.
     Лучшее средство для поиска этих понятий / классов - грифельная
доска, а лучший метод первого уточнения - это беседа со специалистами
в области приложения или просто с друзьями. Обсуждение необходимо,
чтобы создать начальный жизнеспособный словарь терминов и понятийную
структуру. Мало кто может сделать это в одиночку. Обратитесь к [1],
чтобы узнать о методах подобных уточнений.
     Не все классы соответствуют понятиям из области приложения.
Некоторые могут представлять ресурсы системы или абстракции
периода реализации (см. $$12.2.1).
     Взаимоотношения, о которых мы говорим, естественно устанавливаются
в области приложения или (в случае повторных проходов по шагам
проектирования) возникают из последующей работы над структурой классов.
Они отражают наше понимание основ области приложения. Часто они
являются классификацией основных понятий. Пример такого отношения:
машина с выдвижной лестницей есть грузовик, есть пожарная машина,
есть движущееся средство.
В $$11.3.3.2 и $$11.3.3.5 предлагается некоторая точка зрения на
классы и иерархию классов, если необходимо улучшить их структуру.

        11.3.3.2 Шаг 2: определение набора операций

Уточните определения классов, указав набор операций для каждого.
В действительности нельзя разделить процессы определения классов и
выяснения того, какие операции для них нужны. Однако, на практике
они различаются, поскольку при определении классов внимание
концентрируется на основных понятиях, не останавливаясь
на программистских вопросах их реализации, тогда как при определении
операций прежде всего сосредотачивается на том, чтобы задать полный и
удобный набор операций. Часто бывает слишком трудно совместить оба
подхода, в особенности, учитывая, что связанные классы надо
проектировать одновременно.
   Возможно несколько подходов к процессу определения набора операций.
Предлагаем следующую стратегию:
   [1] Рассмотрите, каким образом объект класса будет создаваться,
       копироваться (если нужно) и уничтожаться.
   [2] Определите минимальный набор операций, который необходим
       для понятия, представленного классом.
   [3] Рассмотрите операции, которые могут быть добавлены для удобства
       записи, и включите только несколько действительно важных.
   [4] Рассмотрите, какие операции можно считать тривиальными, т.е.
       такими, для которых класс выступает в роли интерфейса для
       реализации производного класса.
   [5] Рассмотрите, какой общности именования и функциональности
       можно достигнуть для всех классов компонента.
Очевидно, что это - стратегия минимализма. Гораздо проще добавлять
любую функцию, приносящую ощутимую пользу, и сделать все операции
виртуальными. Но, чем больше функций, тем больше вероятность, что
они не будут использоваться, наложат определенные ограничения на
реализацию и затруднят эволюцию системы. Так, функции, которые
могут непосредственно читать и писать в переменную состояния объекта
из класса, вынуждают использовать единственный способ реализации и
значительно сокращают возможности перепроектирования. Такие функции
снижают уровень абстракции от понятия до его конкретной реализации.
К тому же добавление функций добавляет работы программисту и
даже разработчику, когда он вернется к проектированию. Гораздо
легче включить в интерфейс еще одну функцию, как только
установлена потребность в ней, чем удалить ее оттуда, когда уже
она стала привычной.
      Причина, по которой мы требуем явного принятия решения о
виртуальности данной функции, не оставляя его на стадию реализации,
в том, что, объявив функцию виртуальной, мы существенно повлияем
на использование ее класса и на взаимоотношения этого класса с
другими. Объекты из класса, имеющего хотя бы одну виртуальную
функцию, требуют нетривиального распределения памяти, если сравнить
их с объектами из таких языков как С или Фортран. Класс с хотя бы
одной виртуальной функцией по сути выступает в роли интерфейса
по отношению к классам, которые "еще могут быть определены", а
виртуальная функция предполагает зависимость от классов, которые
"еще могу быть определены" (см. $$12.2.3)
     Отметим, что стратегия минимализма требует, пожалуй, больших
усилий со стороны разработчика.
     При определении набора операций больше внимания следует уделять
тому, что надо сделать, а не тому, как это делать.
     Иногда полезно классифицировать операции класса по тому,
как они работают с внутренним состоянием объектов:
  - Базовые операции: конструкторы, деструкторы, операции копирования.
  - Селекторы: операции, не изменяющие состояния объекта.
  - Модификаторы: операции, изменяющие состояние объекта.
  - Операции преобразований, т.е. операции порождающие объект
    другого типа, исходя из значения (состояния) объекта, к которому
    они применяются.
  - Повторители: операции, которые открывают доступ к объектам класса
    или используют последовательность объектов.
Это не есть разбиение на ортогональные группы операций. Например,
повторитель может быть спроектирован как селектор или модификатор.
Выделение этих групп просто предназначено помочь в процессе
проектирования интерфейса класса. Конечно, допустима и другая
классификация. Проведение такой классификации особенно полезно для
поддержания непротиворечивости между классами в рамках одного
компонента.
    В языке С++ есть конструкция, помогающая заданию селекторов и
модификаторов в виде функции-члена со спецификацией const и без нее.
Кроме того, есть средства, позволяющие явно задать конструкторы,
деструкторы и функции преобразования. Операция копирования реализуется
с помощью операций присваивания и конструкторов копирования.

        11.3.3.3 Шаг 3: указание зависимостей

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

        11.3.3.4 Шаг 4: определение интерфейсов

Определите интерфейсы классов. На этой стадии проектирования не нужно
рассматривать приватные функции. Вопросы реализации, возникающие на
стадии проектирования, лучше всего обсуждать на шаге 3 при
рассмотрении различных зависимостей. Более того, существует
золотое правило: если класс не допускает по крайней мере двух
существенно отличающихся реализаций, то что-то явно не в порядке с этим
классом, это просто замаскированная реализация, а не представление
абстрактного понятия. Во многих случаях для ответа на вопрос:
"Достаточно ли интерфейс класса независим от реализации?"- надо
указать, возможна ли для класса схема ленивых вычислений.
   Отметим, что общие базовые классы и друзья (friend) являются
частью общего интерфейса класса (см. $$5.4.1 и $$12.4). Полезным
упражнением может быть определение раздельного интерфейса для
классов-наследников и всех остальных классов с помощью разбиения
интерфейса на общую и закрытые части.
   Именно на этом шаге следует продумать и описать точные определения
типов аргументов. В идеале желательно иметь максимальное число
интерфейсов со статическими типами, относящимися к области приложения
(см. $$12.1.3 и $$12.4).
    При определении интерфейсов следует обратить внимание на те
классы, где набор операций представлен более, чем на одном уровне
абстракции. Например, в классе file у некоторых функций-членов
аргументы имеют тип file_descriptor (дескриптор_файла), а у других
аргументы - строка символов, которая обозначает имя файла.
Операции с file_descriptor работают на другом уровне (меньшем)
абстракции, чем операции с именем файла, так что даже странно,
что они относятся к одному классу. Возможно, было бы лучше иметь
два класса: один представляет понятие дескриптора файла, а
другой - понятие имени файла. Обычно все операции класса должны
представлять понятия одного уровня абстракции. Если это не так,
то стоит подумать о реорганизации и его, и связанных с ним классов.

        11.3.3.5 Перестройка иерархии классов

 Шаги 1 и 3 требуют исследования классов и их иерархии, чтобы
убедиться, что они адекватно отвечают нашим требованиям. Обычно
это не так, и приходится проводить перестройку для улучшения
структуры, проекта или реализации.
     Самая типичная перестройка иерархии классов состоит в выделении
общей части двух классов в новый класс или в разбиении класса на два
новых. В обоих случаях в результате получится три класса:
базовый класс и два
производных. Когда следует проводить такую перестройку? Каковы
общие показания, что такая перестройка будет полезной?
     К сожалению нет простого и универсального ответа на эти
вопросы. Это и не удивительно, поскольку то, что предлагается,
не является мелочью при реализации, а изменяет основные
понятия системы. Важной и нетривиальной задачей является поиск
общности среди классов и выделение общей части.  Нет точного
определения общности, но следует обращать внимание на общность
для понятий системы, а не просто для удобства реализации. Указаниями,
что два класса имеют нечто общее, что возможно выделить в общий базовый
класс, служат схожие способы использования, сходство наборов операций,
сходство реализаций и просто тот факт, что часто в процессе обсуждения
проекта оба   класса   появляются  одновременно.  С другой
стороны,  если  есть
несколько наборов операций класса с различными способами использования,
если эти наборы обеспечивают доступ к раздельным подмножествам объектов
реализации, и, если класс возникает в процессе обсуждения несвязанных
тем, то этот класс является явным кандидатом для разбиения на части.
       В силу тесной связи между понятиями и классами проблемы
перестройки иерархии классов высвечиваются на поверхности проблем
именования классов и использования имен классов в процессе обсуждения
проекта. Если имена классов и их упорядоченность, задаваемая иерархией
классов, кажутся неудобными при обсуждении проекта, значит, по всей
видимости, есть возможность улучшения иерархии. Заметим, что
подразумевается, что анализ иерархии классов лучше проводить не в
одиночку. Если вы оказались в таком положении, когда не с кем
обсудить проект, хорошим выходом будет попытаться составить учебное
описание системы, используя имена классов.

        11.3.3.6 Использование моделей

Когда пишешь статью, пытаешься найти подходящую для темы модель. Нужно
не бросаться сразу печатать текст, а поискать статьи на сходные темы,
вдруг найдется такая, которая может послужить отправной точкой.
Если ею окажется моя собственная статья, то можно будет использовать
даже куски из нее, изменяя по мере надобности другие части, и вводить
новую информацию только там, где требует логика предмета. Таким
образом, исходя из первого издания, написана эта книга. Предельный
случай такого подхода - это написание открытки-формуляра, где просто
нужно указать имя и, возможно, добавить пару строк для придания
"личного" отношения. По сути такие открытки пишутся с указанием отличия
от стандарта.
     Во всех видах творческой деятельности использование существующих
систем в качестве моделей для новых проектов является скорее правилом,
а не исключением. Всегда, когда это возможно, проектирование и
программирование должны основываться на предыдущих работах. Это
сокращает степени свободы для разработчика и позволяет сосредоточить
внимание на меньшем числе вопросов в заданное время. Начать большой
проект "практически с нуля" - это может возбуждать, но правильнее будет
употребить термин "опьянение", которое приведет к "пьяному
блужданию" в множестве вариантов. Построение модели не накладывает
каких-либо ограничений и не означает покорного следования ей, это
просто освобождает разработчика от некоторых вопросов.
     Заметим, что на самом деле использование моделей неизбежно,
поскольку каждый проект синтезируется из опыта его разработчиков.
Лучше, когда использование модели является явно сформулированным
решением, тогда все допущения делаются явно, определяется общий
словарь терминов, появляется начальный каркас проекта и увеличивается
вероятность того, что у разработчиков есть общий подход.
      Естественно, что выбор начальной модели является важным решением,
и обычно оно принимается только после поиска потенциальных моделей
и тщательной оценки вариантов. Более того, во многих случаях модель
подходит только при условии понимания того, что потребуются
значительные изменения для воплощения ее идей в иной области
приложения. Но проектирование программного обеспечения - тяжелый
труд, и надо использовать любую помощь. Не следует отказываться
от использования моделей из-за неоправданного пренебрежения к
имитации. Имитация - не что иное, как форма искреннего восхищения,
а, с учетом права собственности и авторского права, использование
моделей и предшествующих работ в качестве источника вдохновения -
допустимый способ для всех новаторских работ во всех видах
деятельности. То, что было позволено Шекспиру, подходит и для нас.
Некоторые обозначают использование моделей в процессе проектирования
как "проектирование повторного использования".

        11.3.4 Эксперимент и анализ

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