Страница:
организации системы.
Класс может скрывать в себе всякую специфику реализации,
наравне с "грязными" приемами программирования, а иногда он
вынужден это делать. В то же время объекты большинства классов
сами образуют регулярную структуру и используются такими способами,
что их достаточно просто описать. Объект класса может быть
совокупностью других вложенных объектов (их часто называют членами),
многие из которых, в свою очередь, являются указателями или ссылками
на другие объекты. Поэтому отдельный объект можно рассматривать как
корень дерева объектов, а все входящие в него объекты как "иерархию
объектов", которая дополняет иерархию классов, рассмотренную в $$12.2.4.
Рассмотрим в качестве примера класс строк из $$7.6:
class String {
int sz;
char* p;
public:
String(const char* q);
~String();
//...
};
Объект типа String можно изобразить так:
Значение членов или объектов, доступных с помощью членов класса,
называется состоянием объекта (или просто значением объекта).
Главное при построении класса - это: привести объект в полностью
определенное состояние (инициализация), сохранять полностью определенное
состояние обЪекта в процессе выполнения над ним различных операций,
и в конце работы уничтожить объект без всяких последствий. Свойство,
которое делает состояние объекта полностью определенным, называется
инвариантом.
Поэтому назначение инициализации - задать конкретные значения,
при которых выполняется инвариант объекта. Для каждой операции класса
предполагается, что инвариант должен иметь место перед выполнением
операции и должен сохраниться после операции. В конце работы
деструктор нарушает инвариант, уничтожая объект. Например,
конструктор String::String(const char*) гарантирует,
что p указывает на массив из, по крайней мере, sz элементов, причем
sz имеет осмысленное значение и v[sz-1]==0. Любая строковая операция
не должна нарушать это утверждение.
При проектировании класса требуется большое искусство, чтобы
сделать реализацию класса достаточно простой и допускающей
наличие полезных инвариантов, которые несложно задать. Легко
требовать, чтобы класс имел инвариант, труднее предложить полезный
инвариант, который понятен и не накладывает жестких ограничений
на действия разработчика класса или на эффективность реализации.
Здесь "инвариант" понимается как программный фрагмент,
выполнив который, можно проверить состояние объекта. Вполне возможно
дать более строгое и даже математическое определение инварианта, и в
некоторых ситуациях оно может оказаться более подходящим. Здесь же
под инвариантом понимается практическая, а значит, обычно экономная,
но неполная проверка состояния объекта.
Понятие инварианта появилось в работах Флойда, Наура и Хора,
посвященных пред- и пост-условиям, оно встречается во всех важных
статьях по абстрактным типам данных и верификации программ за
последние 20 лет. Оно же является основным предметом отладки в C++.
Обычно, в течение работы функции-члена инвариант не сохраняется.
Поэтому функции, которые могут вызываться в те моменты, когда
инвариант не действует, не должны входить в общий интерфейс класса.
Такие функции должны быть частными или защищенными.
Как можно выразить инвариант в программе на С++? Простое решение -
определить функцию, проверяющую инвариант, и вставить вызовы этой
функции в общие операции. Например:
class String {
int sz;
int* p;
public:
class Range {};
class Invariant {};
void check();
String(const char* q);
~String();
char& operator[](int i);
int size() { return sz; }
//...
};
void String::check()
{
if (p==0 || sz<0 || TOO_LARGE<=sz || p[sz-1])
throw Invariant;
}
char& String::operator[](int i)
{
check(); // проверка на входе
if (i<0 || i<sz) throw Range; // действует
check(); // проверка на выходе
return v[i];
}
Этот вариант прекрасно работает и не осложняет жизнь программиста.
Но для такого простого класса как String проверка инварианта будет
занимать большую часть времени счета. Поэтому программисты обычно
выполняют проверку инварианта только при отладке:
inline void String::check()
{
if (!NDEBUG)
if (p==0 || sz<0 || TOO_LARGE<=sz || p[sz])
throw Invariant;
}
Мы выбрали имя NDEBUG, поскольку это макроопределение, которое
используется для аналогичных целей в стандартном макроопределении
С assert(). Традиционно NDEBUG устанавливается с целью указать,
что отладки нет. Указав, что check() является подстановкой, мы
гарантировали, что никакая программа не будет создана, пока константа
NDEBUG не будет установлена в значение, обозначающее отладку.
С помощью шаблона типа Assert() можно задать менее регулярные
утверждения, например:
template<class T, class X> inline void Assert(T expr,X x)
{
if (!NDEBUG)
if (!expr) throw x;
}
вызовет особую ситуацию x, если expr ложно, и мы не отключили
проверку с помощью NDEBUG. Использовать Assert() можно так:
class Bad_f_arg { };
void f(String& s, int i)
{
Assert(0<=i && i<s.size(),Bad_f_arg());
//...
}
Шаблон типа Assert() подражает макрокоманде assert() языка С.
Если i не находится в требуемом диапазоне, возникает особая
ситуация Bad_f_arg.
С помощью отдельной константы или константы из класса проверить
подобные утверждения или инварианты - пустяковое дело. Если же
необходимо проверить инварианты с помощью объекта, можно определить
производный класс, в котором проверяются операциями из класса, где нет
проверки, см. упр.8 в $$13.11.
Для классов с более сложными операциями расходы на проверки могут
быть значительны, поэтому проверки можно оставить только для "поимки"
трудно обнаруживаемых ошибок. Обычно полезно оставлять по крайней
мере несколько проверок даже в очень хорошо отлаженной программе.
При всех условиях сам факт определения инвариантов и использования
их при отладке дает неоценимую помощь для получения правильной
программы и, что более важно, делает понятия, представленные
классами, более регулярными и строго определенными. Дело в том, что
когда вы создаете инварианты, то рассматриваете класс с другой
точки зрения и вносите определенную избыточность в программу.
То и другое увеличивает вероятность обнаружения ошибок, противоречий
и недосмотров.
Мы указали в $$11.3.3.5, что две самые общие формы преобразования
иерархии классов состоят в разбиении класса на два и в выделении
общей части двух классов в базовый класс. В обоих случаях хорошо
продуманный инвариант может подсказать возможность такого
преобразования. Если, сравнивая инвариант с программами операций,
можно обнаружить, что большинство проверок инварианта излишни,
то значит класс созрел для разбиения. В этом случае подмножество операций
имеет доступ только к подмножеству состояний объекта. Обратно,
классы созрели для слияния, если у них сходные инварианты, даже
при некотором различии в их реализации.
Отметим, что в С++ класс, а не отдельный объект, является той
единицей, которая должна быть инкапсулирована (заключена в оболочку).
Например:
class list {
list* next;
public:
int on(list*);
};
int list::on(list* p)
{
list* q = this;
for(;;) {
if (p == q) return 1;
if (q == 0) return 0;
q = q->next;
}
}
Здесь обращение к частному указателю list::next допустимо, поскольку
list::on() имеет доступ ко всякому объекту класса list, на который
у него есть ссылка. Если это неудобно, ситуацию можно упростить,
отказавшись от возможности доступа через функцию-член к
представлениям других объектов, например:
int list::on(list* p)
{
if (p == this) return 1;
if (p == 0) return 0;
return next->on(p);
}
Но теперь итерация превращается в рекурсию, что может сильно
замедлить выполнение программы, если только транслятор
не сумеет обратно преобразовать рекурсию в итерацию.
Конкретный язык программирования не может прямо поддерживать
любое понятие любого метода проектирования. Если язык программирования
не способен прямо представить понятие проектирования, следует
установить удобное отображение конструкций, используемых в проекте,
на языковые конструкции. Например, метод проектирования может
использовать понятие делегирования, означающее, что всякая
операция, которая не определена для класса A, должна выполняться
в нем с помощью указателя p на соответствующий член класса B,
в котором она определена. На С++ нельзя выразить это прямо. Однако,
реализация этого понятия настолько в духе С++, что легко представить
программу реализации:
class A {
B* p;
//...
void f();
void ff();
};
class B {
//...
void f();
void g();
void h();
};
Тот факт, что В делегирует A с помощью указателя A::p,
выражается в следующей записи:
class A {
B* p; // делегирование с помощью p
//...
void f();
void ff();
void g() { p->g(); } // делегирование q()
void h() { p->h(); } // делегирование h()
};
Для программиста совершенно очевидно, что здесь происходит, однако здесь
явно нарушается принцип взаимнооднозначного соответствия. Такие
"программируемые" отношения трудно выразить на языках программирования,
и поэтому к ним трудно применять различные вспомогательные средства.
Например, такое средство может не отличить "делегирование" от B
к A с помощью A::p от любого другого использования B*.
Все-таки следует всюду, где это возможно, добиваться
взаимнооднозначного соответствия между понятиями проекта и понятиями
языка программирования. Оно дает определенную простоту и гарантирует,
что проект адекватно отображается в программе, что упрощает
работу программиста и вспомогательных средств.
Операции преобразований типа являются механизмом, с помощью которого
можно представить в языке класс программируемых отношений, а именно:
операция преобразования X::operator Y() гарантирует, что всюду,
где допустимо использование Y, можно применять и X. Такое же
отношение задает конструктор Y::Y(X). Отметим, что операция
преобразования типа (как и конструктор) скорее создает новый объект,
чем изменяет тип существующего объекта. Задать операцию преобразования
к функции Y - означает просто потребовать неявного применения
функции, возвращающей Y. Поскольку неявные применения операций
преобразования типа и операций, определяемых конструкторами, могут
привести к неприятностям, полезно проанализировать их в отдельности
еще в проекте.
Важно убедиться, что граф применений операций преобразования типа
не содержит циклов. Если они есть, возникает двусмысленная ситуация,
при которой типы, участвующие в циклах, становятся несовместимыми в
комбинации. Например:
class Big_int {
//...
friend Big_int operator+(Big_int,Big_int);
//...
operator Rational();
//...
};
class Rational {
//...
friend Rational operator+(Rational,Rational);
//...
operator Big_int();
};
Типы Rational и Big_int не так гладко взаимодействуют, как можно
было бы подумать:
void f(Rational r, Big_int i)
{
//...
g(r+i); // ошибка, неоднозначность:
// operator+(r,Rational(i)) или
// operator+(Big_int(r),i)
g(r,Rational(i)); // явное разрешение неопределенности
g(Big_int(r),i); // еще одно
}
Можно было бы избежать таких "взаимных" преобразований, сделав
некоторые из них явными. Например, преобразование Big_int к типу
Rational можно было бы задать явно с помощью функции make_Rational()
вместо операции преобразования, тогда сложение в приведенном
примере разрешалось бы как g(BIg_int(r),i). Если нельзя избежать
"взаимных" операций преобразования типов, то нужно преодолевать
возникающие столкновения или с помощью явных преобразований (как было
показано), или с помощью определения нескольких различных версий
бинарной операции (в нашем случае +).
В языке С++ нет конструкций, которые могут выразить прямо в программе
понятие компонента, т.е. множества связанных классов. Основная
причина этого в том, что множество классов (возможно с соответствующими
глобальными функциями и т.п.) может соединяться в компонент по
самым разным признакам. Отсутствие явного представления понятия в
языке затрудняет проведение границы между информацией (имена),
используемой внутри компонента, и информацией (имена), передаваемой
из компонента пользователям.
В идеале, компонент определяется множеством интерфейсов, используемых
для его реализации, плюс множеством интерфейсов, представляемых
пользователем, а все прочее считается "спецификой реализации" и
должно быть скрыто от остальных частей системы. Таково может быть
в действительности представление о компоненте у разработчика.
Программист должен смириться с тем фактом, что С++ не дает
общего понятия пространства имен компонента, так что его
приходится "моделировать" с помощью понятий классов и единиц
трансляции, т.е. тех средств, которые есть в С++ для ограничения
области действия нелокальных имен.
Рассмотрим два класса, которые должны совместно использовать
функцию f() и переменную v. Проще всего описать f и v как
глобальные имена. Однако, всякий опытный программист знает, что
такое "засорение" пространства имен может привести в конце концов
к неприятностям: кто-то может ненарочно использовать имена f или v
не по назначению или нарочно обратиться к f или v,
прямо используя "специфику реализации" и обойдя тем самым явный
интерфейс компонента. Здесь возможны три решения:
[1] Дать "необычные" имена объектам и функциям, которые не
рассчитаны на пользователя.
[2] Объекты или функции, не предназначенные для пользователя,
описать в одном из файлов программы как статические (static).
[3] Поместить объекты и функции, не предназначенные для пользователя,
в класс, определение которого закрыто для пользователей.
Первое решение примитивно и достаточно неудобно для создателя
программы, но оно действует:
// не используйте специфику реализации compX,
// если только вы не разработчик compX:
extern void compX_f(T2*, const char*);
extern T3 compX_v;
// ...
Такие имена как compX_f и compX_v вряд ли могут привести к коллизии, а на
тот довод, что пользователь может быть злоумышленником и использовать
эти имена прямо, можно ответить, что пользователь в любом случае может
оказаться злоумышленником, и что языковые механизмы защиты предохраняют
от несчастного случая, а не от злого умысла. Преимущество этого
решения в том, что оно применимо всегда и хорошо известно. В то же
время оно некрасиво, ненадежно и усложняет ввод текста.
Второе решение более надежно, но менее универсально:
// специфика реализации compX:
static void compX_f(T2* a1, const char *a2) { /* ... */ }
static T3 compX_v;
// ...
Трудно гарантировать, что информация, используемая в классах одного
компонента, будет доступна только в одной единице трансляции,
поскольку операции, работающие с этой информацией, должны
быть доступны везде. Это решение может к тому же привести к
громадным единицам трансляции, а в некоторых отладчиках для С++
не организован доступ к именам статических функций и переменных.
В то же время это решение надежно и часто оптимально для небольших
компонентов.
Третье решение можно рассматривать как формализацию и обобщение
первых двух:
class compX_details { // специфика реализации compX
public:
static void f(T2*, const char*);
static T3 v;
// ...
};
Описание compX_details будет использовать только создатель класса,
остальные не должны включать его в свои программы.
В компоненте конечно может быть много классов, не предназначенных
для общего пользования. Если их имена тоже рассчитаны только на
локальное использование, то их также можно "спрятать" внутри
классов, содержащих специфику реализации:
class compX_details { // специфика реализации compX.
public:
// ...
class widget {
// ...
};
// ...
};
Укажем, что вложенность создает барьер для использования widget
в других частях программы. Обычно классы, представляющие
ясные понятия, считаются первыми кандидатами на повторное
использование, и, значит составляют часть интерфейса компонента,
а не деталь реализации. Другими словами, хотя для сохранения
надлежащего уровня абстракции вложенные объекты, используемые для
представления некоторого объекта класса, лучше считать скрытыми
деталями реализации, классы, определяющие такие вложенные объекты,
лучше не делать скрытыми, если они имеют достаточную общность.
Так, в следующем примере упрятывание, пожалуй, излишне:
class Car {
class Wheel {
// ...
};
Wheel flw, frw, rlw, rrw;
// ...
};
Во многих ситуациях для поддержания уровня абстракции понятия
машины (Car) следует упрятывать реальные колеса (класс Wheel),
ведь когда вы работаете с машиной, вы не можете независимо от нее
использовать колеса. С другой стороны, сам класс Wheel является
вполне подходящим для широкого использования, поэтому лучше
вынести его определение из класса Car:
class Wheel {
// ...
};
class Car {
Wheel flw, frw, rlw, rrw;
// ...
};
Использовать ли вложенность? Ответ на этот вопрос зависит
от целей проекта и общности используемых понятий. Как вложенность,
так и ее отсутствие могут быть вполне допустимыми решениями для данного
проекта. Но поскольку вложенность предохраняет от засорения
общего пространства имен, в своде правил ниже рекомендуется
использовать вложенность, если только нет причин не делать этого.
Отметим, что заголовочные файлы дают мощное средство для
различных представлений компонент разным пользователям, и они же
позволяют удалять из представления компонента для пользователя те
классы, которые связаны со спецификой реализации.
Другим средством построения компонента и представления его
пользователю служит иерархия. Тогда базовый класс используется как
хранилище общих данных и функций. Таким способом устраняется
проблема, связанная с глобальными данными и функциями, предназначенными
для реализации общих запросов классов данного компонента.
С другой стороны, при таком решении классы компонента становятся
слишком связанными друг с другом, а пользователь попадает в зависимость
от всех базовых классов тех компонентов, которые ему действительно
нужны. Здесь также проявляется тенденция к тому, что члены,
представляющие "полезные" функции и данные "всплывают" к базовому
классу, так что при слишком большой иерархии классов проблемы с
глобальными данными и функциями проявятся уже в рамках этой иерархии.
Вероятнее всего, это произойдет для иерархии с одним корнем, а для
борьбы с этим явлением можно применять виртуальные базовые классы
($$6.5.4). Иногда лучше выбрать иерархию для представления компонента,
а иногда нет. Как всегда сделать выбор предстоит разработчику.
Идеальный интерфейс должен
- представлять полное и согласованное множество понятий для
пользователя,
- быть согласованным для всех частей компонента,
- скрывать специфику реализации от пользователя,
- допускать несколько реализаций,
- иметь статическую систему типов,
- определяться с помощью типов из области приложения,
- зависеть от других интерфейсов лишь частично и вполне определенным
образом.
Отметив необходимость согласованности для всех классов, которые
образуют интерфейс компонента с остальным миром, мы можем упростить
вопрос интерфейса, рассмотрев только один класс, например:
class X { // пример плохого определения интерфейса
Y a;
Z b;
public:
void f(const char* ...);
void g(int[],int);
void set_a(Y&);
Y& get_a();
};
В этом интерфейсе содержится ряд потенциальных проблем:
-Типы Y и Z используются так, что определения Y и Z должны быть
известны во время трансляции.
- У функции X::f может быть произвольное число параметров
неизвестного типа (возможно, они каким-то образом контролируются
"строкой формата", которая передается в качестве первого
параметра).
- Функция X::g имеет параметр типа int[]. Возможно это нормально,
но обычно это свидетельствует о том, что определение слишком
низкого уровня абстракции. Массив целых не является достаточным
определением, так как неизвестно из скольких он может
состоять элементов.
- Функции set_a() и get_a(), по всей видимости, раскрывают
представление объектов класса X, разрешая прямой доступ
к X::a.
Здесь функции-члены образуют интерфейс на слишком низком уровне
абстракции. Как правило классы с интерфейсом такого уровня относятся
к специфике реализации большого компонента, если они вообще могут
к чему-нибудь относиться. В идеале параметр функции из интерфейса
должен сопровождаться такой информацией, которой достаточно
для его понимания. Можно сформулировать такое правило: надо уметь
передавать запросы на обслуживание удаленному серверу по узкому
каналу.
Язык С++ раскрывает представление класса как часть интерфейса.
Это представление может быть скрытым (с помощью private или
protected), но обязательно доступным транслятору, чтобы он мог разместить
автоматические (локальные) переменные, сделать подстановку тела
функции и т.д. Отрицательным следствием этого является то, что
использование типов классов в представлении класса может привести к
возникновению нежелательных зависимостей. Приведет ли использование
членов типа Y и Z к проблемам, зависит от того, каковы в действительности
типы Y и Z. Если это достаточно простые типы, наподобие complex или
String, то их использование будет вполне допустимым в большинстве случаев.
Такие типы можно считать устойчивыми, и необходимость включать
определения их классов будет вполне допустимой нагрузкой для транслятора.
Если же Y и Z сами являются классами интерфейса большого
компонента (например, типа графической системы или системы обеспечения
банковских счетов), то прямую зависимость от них можно считать
неразумной. В таких случаях предпочтительнее использовать член,
являющийся указателем или ссылкой:
class X {
Y* a;
Z& b;
// ...
};
При этом способе определение X отделяется от определений Y и Z, т.е.
теперь определение X зависит только от имен Y и Z. Реализация X,
конечно, будет по-прежнему зависеть от определений Y и Z, но это
уже не будет оказывать неблагоприятного влияния на пользователей X.
Вышесказанное иллюстрирует важное утверждение: У интерфейса,
скрывающего значительный объем информации (что и должен делать полезный
интерфейс), должно быть существенно меньше зависимостей, чем
у реализации, которая их скрывает. Например, определение класса X
можно транслировать без доступа к определениям Y и Z. Однако,
в определениях функций-членов класса X, которые работают со
ссылками на объекты Y и Z, доступ к определениям Y и Z необходим.
При анализе зависимостей следует рассматривать раздельно
зависимости в интерфейсе и в реализации. В идеале для обоих видов
зависимостей граф зависимостей системы должен быть направленным
нецикличным графом, что облегчает понимание и тестирование
системы. Однако, эта цель более важна и чаще достижима для
реализаций, чем для интерфейсов.
Отметим, что класс определяет три интерфейса:
class X {
private:
// доступно только для членов и друзей
protected:
// доступно только для членов и друзей, а также
// для членов и друзей производных классов
public:
// общедоступно
};
Члены должны образовывать самый ограниченный из возможных интерфейсов.
Иными словами, член должен быть описан как private, если нет
причин для более широкого доступа к нему; если же таковые есть, то
член должен быть описан как protected, если нет дополнительных причин
задать его как public. В большинстве случаев плохо задавать все данные,
представляемые членами, как public. Функции и классы, образующие общий
интерфейс, должны быть спроектированы таким образом, чтобы представление
класса совпадало с его ролью в проекте как средства представления
понятий. Напомним, что друзья являются частью общего интерфейса.
Отметим, что абстрактные классы можно использовать для
представления понятия упрятывания более высокого уровня ($$1.4.6,
$$6.3, $$13.3).
В этой главе мы коснулись многих тем, но, как правило, избегали
давать настоятельные и конкретные рекомендации по рассматриваемым
вопросам. Это отвечает моему убеждению, что нет "единственно верного
решения". Принципы и приемы следует применять способом, наиболее
подходящим для конкретной задачи. Здесь требуются вкус, опыт и
разум. Тем не менее, можно предложить свод правил, которые
разработчик может использовать в качестве ориентиров, пока не
приобретет достаточно опыта, чтобы выработать лучшие.
Этот свод правил приводится ниже.
Он может служить отправной точкой в процессе выработки
основных направлений проекта конкретной задачи, или же он может
использоваться организацией в качестве проверочного списка. Подчеркну
еще раз, что эти правила не являются универсальными и не могут
заменить собой размышления.
- Нацеливайте пользователя на применение абстракции данных и
объектно-ориентированного программирования.
- Постепенно переходите на новые методы, не спешите.
- Используйте возможности С++ и методы обЪектно-ориентированного
программирования только по мере надобности.
_ Добейтесь соответствия стиля проекта и программы.
- Концентрируйте внимание на проектировании компонента.
_ Используйте классы для представления понятий.
- Используйте общее наследование для представления отношений "есть".
- Используйте принадлежность для представления отношений "имеет".
- Убедитесь, что отношения использования понятны, не образуют
циклов, и что число их минимально.
- Активно ищите общность среди понятий области приложения и
реализации, и возникающие в результате более общие понятия
представляйте как базовые классы.
- Определяйте интерфейс так, чтобы открывать минимальное количество
требуемой информации:
- Используйте, всюду где это можно, частные данные и функции-члены.
- Используйте описания public или protected, чтобы отличить
запросы разработчика производных классов от запросов обычных
пользователей.
- Сведите к минимуму зависимости одного интерфейса от других.
- Поддерживайте строгую типизацию интерфейсов.
- Задавайте интерфейсы в терминах типов из области приложения.
Дополнительные правила можно найти $$11.5.
Класс может скрывать в себе всякую специфику реализации,
наравне с "грязными" приемами программирования, а иногда он
вынужден это делать. В то же время объекты большинства классов
сами образуют регулярную структуру и используются такими способами,
что их достаточно просто описать. Объект класса может быть
совокупностью других вложенных объектов (их часто называют членами),
многие из которых, в свою очередь, являются указателями или ссылками
на другие объекты. Поэтому отдельный объект можно рассматривать как
корень дерева объектов, а все входящие в него объекты как "иерархию
объектов", которая дополняет иерархию классов, рассмотренную в $$12.2.4.
Рассмотрим в качестве примера класс строк из $$7.6:
class String {
int sz;
char* p;
public:
String(const char* q);
~String();
//...
};
Объект типа String можно изобразить так:
Значение членов или объектов, доступных с помощью членов класса,
называется состоянием объекта (или просто значением объекта).
Главное при построении класса - это: привести объект в полностью
определенное состояние (инициализация), сохранять полностью определенное
состояние обЪекта в процессе выполнения над ним различных операций,
и в конце работы уничтожить объект без всяких последствий. Свойство,
которое делает состояние объекта полностью определенным, называется
инвариантом.
Поэтому назначение инициализации - задать конкретные значения,
при которых выполняется инвариант объекта. Для каждой операции класса
предполагается, что инвариант должен иметь место перед выполнением
операции и должен сохраниться после операции. В конце работы
деструктор нарушает инвариант, уничтожая объект. Например,
конструктор String::String(const char*) гарантирует,
что p указывает на массив из, по крайней мере, sz элементов, причем
sz имеет осмысленное значение и v[sz-1]==0. Любая строковая операция
не должна нарушать это утверждение.
При проектировании класса требуется большое искусство, чтобы
сделать реализацию класса достаточно простой и допускающей
наличие полезных инвариантов, которые несложно задать. Легко
требовать, чтобы класс имел инвариант, труднее предложить полезный
инвариант, который понятен и не накладывает жестких ограничений
на действия разработчика класса или на эффективность реализации.
Здесь "инвариант" понимается как программный фрагмент,
выполнив который, можно проверить состояние объекта. Вполне возможно
дать более строгое и даже математическое определение инварианта, и в
некоторых ситуациях оно может оказаться более подходящим. Здесь же
под инвариантом понимается практическая, а значит, обычно экономная,
но неполная проверка состояния объекта.
Понятие инварианта появилось в работах Флойда, Наура и Хора,
посвященных пред- и пост-условиям, оно встречается во всех важных
статьях по абстрактным типам данных и верификации программ за
последние 20 лет. Оно же является основным предметом отладки в C++.
Обычно, в течение работы функции-члена инвариант не сохраняется.
Поэтому функции, которые могут вызываться в те моменты, когда
инвариант не действует, не должны входить в общий интерфейс класса.
Такие функции должны быть частными или защищенными.
Как можно выразить инвариант в программе на С++? Простое решение -
определить функцию, проверяющую инвариант, и вставить вызовы этой
функции в общие операции. Например:
class String {
int sz;
int* p;
public:
class Range {};
class Invariant {};
void check();
String(const char* q);
~String();
char& operator[](int i);
int size() { return sz; }
//...
};
void String::check()
{
if (p==0 || sz<0 || TOO_LARGE<=sz || p[sz-1])
throw Invariant;
}
char& String::operator[](int i)
{
check(); // проверка на входе
if (i<0 || i<sz) throw Range; // действует
check(); // проверка на выходе
return v[i];
}
Этот вариант прекрасно работает и не осложняет жизнь программиста.
Но для такого простого класса как String проверка инварианта будет
занимать большую часть времени счета. Поэтому программисты обычно
выполняют проверку инварианта только при отладке:
inline void String::check()
{
if (!NDEBUG)
if (p==0 || sz<0 || TOO_LARGE<=sz || p[sz])
throw Invariant;
}
Мы выбрали имя NDEBUG, поскольку это макроопределение, которое
используется для аналогичных целей в стандартном макроопределении
С assert(). Традиционно NDEBUG устанавливается с целью указать,
что отладки нет. Указав, что check() является подстановкой, мы
гарантировали, что никакая программа не будет создана, пока константа
NDEBUG не будет установлена в значение, обозначающее отладку.
С помощью шаблона типа Assert() можно задать менее регулярные
утверждения, например:
template<class T, class X> inline void Assert(T expr,X x)
{
if (!NDEBUG)
if (!expr) throw x;
}
вызовет особую ситуацию x, если expr ложно, и мы не отключили
проверку с помощью NDEBUG. Использовать Assert() можно так:
class Bad_f_arg { };
void f(String& s, int i)
{
Assert(0<=i && i<s.size(),Bad_f_arg());
//...
}
Шаблон типа Assert() подражает макрокоманде assert() языка С.
Если i не находится в требуемом диапазоне, возникает особая
ситуация Bad_f_arg.
С помощью отдельной константы или константы из класса проверить
подобные утверждения или инварианты - пустяковое дело. Если же
необходимо проверить инварианты с помощью объекта, можно определить
производный класс, в котором проверяются операциями из класса, где нет
проверки, см. упр.8 в $$13.11.
Для классов с более сложными операциями расходы на проверки могут
быть значительны, поэтому проверки можно оставить только для "поимки"
трудно обнаруживаемых ошибок. Обычно полезно оставлять по крайней
мере несколько проверок даже в очень хорошо отлаженной программе.
При всех условиях сам факт определения инвариантов и использования
их при отладке дает неоценимую помощь для получения правильной
программы и, что более важно, делает понятия, представленные
классами, более регулярными и строго определенными. Дело в том, что
когда вы создаете инварианты, то рассматриваете класс с другой
точки зрения и вносите определенную избыточность в программу.
То и другое увеличивает вероятность обнаружения ошибок, противоречий
и недосмотров.
Мы указали в $$11.3.3.5, что две самые общие формы преобразования
иерархии классов состоят в разбиении класса на два и в выделении
общей части двух классов в базовый класс. В обоих случаях хорошо
продуманный инвариант может подсказать возможность такого
преобразования. Если, сравнивая инвариант с программами операций,
можно обнаружить, что большинство проверок инварианта излишни,
то значит класс созрел для разбиения. В этом случае подмножество операций
имеет доступ только к подмножеству состояний объекта. Обратно,
классы созрели для слияния, если у них сходные инварианты, даже
при некотором различии в их реализации.
Отметим, что в С++ класс, а не отдельный объект, является той
единицей, которая должна быть инкапсулирована (заключена в оболочку).
Например:
class list {
list* next;
public:
int on(list*);
};
int list::on(list* p)
{
list* q = this;
for(;;) {
if (p == q) return 1;
if (q == 0) return 0;
q = q->next;
}
}
Здесь обращение к частному указателю list::next допустимо, поскольку
list::on() имеет доступ ко всякому объекту класса list, на который
у него есть ссылка. Если это неудобно, ситуацию можно упростить,
отказавшись от возможности доступа через функцию-член к
представлениям других объектов, например:
int list::on(list* p)
{
if (p == this) return 1;
if (p == 0) return 0;
return next->on(p);
}
Но теперь итерация превращается в рекурсию, что может сильно
замедлить выполнение программы, если только транслятор
не сумеет обратно преобразовать рекурсию в итерацию.
Конкретный язык программирования не может прямо поддерживать
любое понятие любого метода проектирования. Если язык программирования
не способен прямо представить понятие проектирования, следует
установить удобное отображение конструкций, используемых в проекте,
на языковые конструкции. Например, метод проектирования может
использовать понятие делегирования, означающее, что всякая
операция, которая не определена для класса A, должна выполняться
в нем с помощью указателя p на соответствующий член класса B,
в котором она определена. На С++ нельзя выразить это прямо. Однако,
реализация этого понятия настолько в духе С++, что легко представить
программу реализации:
class A {
B* p;
//...
void f();
void ff();
};
class B {
//...
void f();
void g();
void h();
};
Тот факт, что В делегирует A с помощью указателя A::p,
выражается в следующей записи:
class A {
B* p; // делегирование с помощью p
//...
void f();
void ff();
void g() { p->g(); } // делегирование q()
void h() { p->h(); } // делегирование h()
};
Для программиста совершенно очевидно, что здесь происходит, однако здесь
явно нарушается принцип взаимнооднозначного соответствия. Такие
"программируемые" отношения трудно выразить на языках программирования,
и поэтому к ним трудно применять различные вспомогательные средства.
Например, такое средство может не отличить "делегирование" от B
к A с помощью A::p от любого другого использования B*.
Все-таки следует всюду, где это возможно, добиваться
взаимнооднозначного соответствия между понятиями проекта и понятиями
языка программирования. Оно дает определенную простоту и гарантирует,
что проект адекватно отображается в программе, что упрощает
работу программиста и вспомогательных средств.
Операции преобразований типа являются механизмом, с помощью которого
можно представить в языке класс программируемых отношений, а именно:
операция преобразования X::operator Y() гарантирует, что всюду,
где допустимо использование Y, можно применять и X. Такое же
отношение задает конструктор Y::Y(X). Отметим, что операция
преобразования типа (как и конструктор) скорее создает новый объект,
чем изменяет тип существующего объекта. Задать операцию преобразования
к функции Y - означает просто потребовать неявного применения
функции, возвращающей Y. Поскольку неявные применения операций
преобразования типа и операций, определяемых конструкторами, могут
привести к неприятностям, полезно проанализировать их в отдельности
еще в проекте.
Важно убедиться, что граф применений операций преобразования типа
не содержит циклов. Если они есть, возникает двусмысленная ситуация,
при которой типы, участвующие в циклах, становятся несовместимыми в
комбинации. Например:
class Big_int {
//...
friend Big_int operator+(Big_int,Big_int);
//...
operator Rational();
//...
};
class Rational {
//...
friend Rational operator+(Rational,Rational);
//...
operator Big_int();
};
Типы Rational и Big_int не так гладко взаимодействуют, как можно
было бы подумать:
void f(Rational r, Big_int i)
{
//...
g(r+i); // ошибка, неоднозначность:
// operator+(r,Rational(i)) или
// operator+(Big_int(r),i)
g(r,Rational(i)); // явное разрешение неопределенности
g(Big_int(r),i); // еще одно
}
Можно было бы избежать таких "взаимных" преобразований, сделав
некоторые из них явными. Например, преобразование Big_int к типу
Rational можно было бы задать явно с помощью функции make_Rational()
вместо операции преобразования, тогда сложение в приведенном
примере разрешалось бы как g(BIg_int(r),i). Если нельзя избежать
"взаимных" операций преобразования типов, то нужно преодолевать
возникающие столкновения или с помощью явных преобразований (как было
показано), или с помощью определения нескольких различных версий
бинарной операции (в нашем случае +).
В языке С++ нет конструкций, которые могут выразить прямо в программе
понятие компонента, т.е. множества связанных классов. Основная
причина этого в том, что множество классов (возможно с соответствующими
глобальными функциями и т.п.) может соединяться в компонент по
самым разным признакам. Отсутствие явного представления понятия в
языке затрудняет проведение границы между информацией (имена),
используемой внутри компонента, и информацией (имена), передаваемой
из компонента пользователям.
В идеале, компонент определяется множеством интерфейсов, используемых
для его реализации, плюс множеством интерфейсов, представляемых
пользователем, а все прочее считается "спецификой реализации" и
должно быть скрыто от остальных частей системы. Таково может быть
в действительности представление о компоненте у разработчика.
Программист должен смириться с тем фактом, что С++ не дает
общего понятия пространства имен компонента, так что его
приходится "моделировать" с помощью понятий классов и единиц
трансляции, т.е. тех средств, которые есть в С++ для ограничения
области действия нелокальных имен.
Рассмотрим два класса, которые должны совместно использовать
функцию f() и переменную v. Проще всего описать f и v как
глобальные имена. Однако, всякий опытный программист знает, что
такое "засорение" пространства имен может привести в конце концов
к неприятностям: кто-то может ненарочно использовать имена f или v
не по назначению или нарочно обратиться к f или v,
прямо используя "специфику реализации" и обойдя тем самым явный
интерфейс компонента. Здесь возможны три решения:
[1] Дать "необычные" имена объектам и функциям, которые не
рассчитаны на пользователя.
[2] Объекты или функции, не предназначенные для пользователя,
описать в одном из файлов программы как статические (static).
[3] Поместить объекты и функции, не предназначенные для пользователя,
в класс, определение которого закрыто для пользователей.
Первое решение примитивно и достаточно неудобно для создателя
программы, но оно действует:
// не используйте специфику реализации compX,
// если только вы не разработчик compX:
extern void compX_f(T2*, const char*);
extern T3 compX_v;
// ...
Такие имена как compX_f и compX_v вряд ли могут привести к коллизии, а на
тот довод, что пользователь может быть злоумышленником и использовать
эти имена прямо, можно ответить, что пользователь в любом случае может
оказаться злоумышленником, и что языковые механизмы защиты предохраняют
от несчастного случая, а не от злого умысла. Преимущество этого
решения в том, что оно применимо всегда и хорошо известно. В то же
время оно некрасиво, ненадежно и усложняет ввод текста.
Второе решение более надежно, но менее универсально:
// специфика реализации compX:
static void compX_f(T2* a1, const char *a2) { /* ... */ }
static T3 compX_v;
// ...
Трудно гарантировать, что информация, используемая в классах одного
компонента, будет доступна только в одной единице трансляции,
поскольку операции, работающие с этой информацией, должны
быть доступны везде. Это решение может к тому же привести к
громадным единицам трансляции, а в некоторых отладчиках для С++
не организован доступ к именам статических функций и переменных.
В то же время это решение надежно и часто оптимально для небольших
компонентов.
Третье решение можно рассматривать как формализацию и обобщение
первых двух:
class compX_details { // специфика реализации compX
public:
static void f(T2*, const char*);
static T3 v;
// ...
};
Описание compX_details будет использовать только создатель класса,
остальные не должны включать его в свои программы.
В компоненте конечно может быть много классов, не предназначенных
для общего пользования. Если их имена тоже рассчитаны только на
локальное использование, то их также можно "спрятать" внутри
классов, содержащих специфику реализации:
class compX_details { // специфика реализации compX.
public:
// ...
class widget {
// ...
};
// ...
};
Укажем, что вложенность создает барьер для использования widget
в других частях программы. Обычно классы, представляющие
ясные понятия, считаются первыми кандидатами на повторное
использование, и, значит составляют часть интерфейса компонента,
а не деталь реализации. Другими словами, хотя для сохранения
надлежащего уровня абстракции вложенные объекты, используемые для
представления некоторого объекта класса, лучше считать скрытыми
деталями реализации, классы, определяющие такие вложенные объекты,
лучше не делать скрытыми, если они имеют достаточную общность.
Так, в следующем примере упрятывание, пожалуй, излишне:
class Car {
class Wheel {
// ...
};
Wheel flw, frw, rlw, rrw;
// ...
};
Во многих ситуациях для поддержания уровня абстракции понятия
машины (Car) следует упрятывать реальные колеса (класс Wheel),
ведь когда вы работаете с машиной, вы не можете независимо от нее
использовать колеса. С другой стороны, сам класс Wheel является
вполне подходящим для широкого использования, поэтому лучше
вынести его определение из класса Car:
class Wheel {
// ...
};
class Car {
Wheel flw, frw, rlw, rrw;
// ...
};
Использовать ли вложенность? Ответ на этот вопрос зависит
от целей проекта и общности используемых понятий. Как вложенность,
так и ее отсутствие могут быть вполне допустимыми решениями для данного
проекта. Но поскольку вложенность предохраняет от засорения
общего пространства имен, в своде правил ниже рекомендуется
использовать вложенность, если только нет причин не делать этого.
Отметим, что заголовочные файлы дают мощное средство для
различных представлений компонент разным пользователям, и они же
позволяют удалять из представления компонента для пользователя те
классы, которые связаны со спецификой реализации.
Другим средством построения компонента и представления его
пользователю служит иерархия. Тогда базовый класс используется как
хранилище общих данных и функций. Таким способом устраняется
проблема, связанная с глобальными данными и функциями, предназначенными
для реализации общих запросов классов данного компонента.
С другой стороны, при таком решении классы компонента становятся
слишком связанными друг с другом, а пользователь попадает в зависимость
от всех базовых классов тех компонентов, которые ему действительно
нужны. Здесь также проявляется тенденция к тому, что члены,
представляющие "полезные" функции и данные "всплывают" к базовому
классу, так что при слишком большой иерархии классов проблемы с
глобальными данными и функциями проявятся уже в рамках этой иерархии.
Вероятнее всего, это произойдет для иерархии с одним корнем, а для
борьбы с этим явлением можно применять виртуальные базовые классы
($$6.5.4). Иногда лучше выбрать иерархию для представления компонента,
а иногда нет. Как всегда сделать выбор предстоит разработчику.
Идеальный интерфейс должен
- представлять полное и согласованное множество понятий для
пользователя,
- быть согласованным для всех частей компонента,
- скрывать специфику реализации от пользователя,
- допускать несколько реализаций,
- иметь статическую систему типов,
- определяться с помощью типов из области приложения,
- зависеть от других интерфейсов лишь частично и вполне определенным
образом.
Отметив необходимость согласованности для всех классов, которые
образуют интерфейс компонента с остальным миром, мы можем упростить
вопрос интерфейса, рассмотрев только один класс, например:
class X { // пример плохого определения интерфейса
Y a;
Z b;
public:
void f(const char* ...);
void g(int[],int);
void set_a(Y&);
Y& get_a();
};
В этом интерфейсе содержится ряд потенциальных проблем:
-Типы Y и Z используются так, что определения Y и Z должны быть
известны во время трансляции.
- У функции X::f может быть произвольное число параметров
неизвестного типа (возможно, они каким-то образом контролируются
"строкой формата", которая передается в качестве первого
параметра).
- Функция X::g имеет параметр типа int[]. Возможно это нормально,
но обычно это свидетельствует о том, что определение слишком
низкого уровня абстракции. Массив целых не является достаточным
определением, так как неизвестно из скольких он может
состоять элементов.
- Функции set_a() и get_a(), по всей видимости, раскрывают
представление объектов класса X, разрешая прямой доступ
к X::a.
Здесь функции-члены образуют интерфейс на слишком низком уровне
абстракции. Как правило классы с интерфейсом такого уровня относятся
к специфике реализации большого компонента, если они вообще могут
к чему-нибудь относиться. В идеале параметр функции из интерфейса
должен сопровождаться такой информацией, которой достаточно
для его понимания. Можно сформулировать такое правило: надо уметь
передавать запросы на обслуживание удаленному серверу по узкому
каналу.
Язык С++ раскрывает представление класса как часть интерфейса.
Это представление может быть скрытым (с помощью private или
protected), но обязательно доступным транслятору, чтобы он мог разместить
автоматические (локальные) переменные, сделать подстановку тела
функции и т.д. Отрицательным следствием этого является то, что
использование типов классов в представлении класса может привести к
возникновению нежелательных зависимостей. Приведет ли использование
членов типа Y и Z к проблемам, зависит от того, каковы в действительности
типы Y и Z. Если это достаточно простые типы, наподобие complex или
String, то их использование будет вполне допустимым в большинстве случаев.
Такие типы можно считать устойчивыми, и необходимость включать
определения их классов будет вполне допустимой нагрузкой для транслятора.
Если же Y и Z сами являются классами интерфейса большого
компонента (например, типа графической системы или системы обеспечения
банковских счетов), то прямую зависимость от них можно считать
неразумной. В таких случаях предпочтительнее использовать член,
являющийся указателем или ссылкой:
class X {
Y* a;
Z& b;
// ...
};
При этом способе определение X отделяется от определений Y и Z, т.е.
теперь определение X зависит только от имен Y и Z. Реализация X,
конечно, будет по-прежнему зависеть от определений Y и Z, но это
уже не будет оказывать неблагоприятного влияния на пользователей X.
Вышесказанное иллюстрирует важное утверждение: У интерфейса,
скрывающего значительный объем информации (что и должен делать полезный
интерфейс), должно быть существенно меньше зависимостей, чем
у реализации, которая их скрывает. Например, определение класса X
можно транслировать без доступа к определениям Y и Z. Однако,
в определениях функций-членов класса X, которые работают со
ссылками на объекты Y и Z, доступ к определениям Y и Z необходим.
При анализе зависимостей следует рассматривать раздельно
зависимости в интерфейсе и в реализации. В идеале для обоих видов
зависимостей граф зависимостей системы должен быть направленным
нецикличным графом, что облегчает понимание и тестирование
системы. Однако, эта цель более важна и чаще достижима для
реализаций, чем для интерфейсов.
Отметим, что класс определяет три интерфейса:
class X {
private:
// доступно только для членов и друзей
protected:
// доступно только для членов и друзей, а также
// для членов и друзей производных классов
public:
// общедоступно
};
Члены должны образовывать самый ограниченный из возможных интерфейсов.
Иными словами, член должен быть описан как private, если нет
причин для более широкого доступа к нему; если же таковые есть, то
член должен быть описан как protected, если нет дополнительных причин
задать его как public. В большинстве случаев плохо задавать все данные,
представляемые членами, как public. Функции и классы, образующие общий
интерфейс, должны быть спроектированы таким образом, чтобы представление
класса совпадало с его ролью в проекте как средства представления
понятий. Напомним, что друзья являются частью общего интерфейса.
Отметим, что абстрактные классы можно использовать для
представления понятия упрятывания более высокого уровня ($$1.4.6,
$$6.3, $$13.3).
В этой главе мы коснулись многих тем, но, как правило, избегали
давать настоятельные и конкретные рекомендации по рассматриваемым
вопросам. Это отвечает моему убеждению, что нет "единственно верного
решения". Принципы и приемы следует применять способом, наиболее
подходящим для конкретной задачи. Здесь требуются вкус, опыт и
разум. Тем не менее, можно предложить свод правил, которые
разработчик может использовать в качестве ориентиров, пока не
приобретет достаточно опыта, чтобы выработать лучшие.
Этот свод правил приводится ниже.
Он может служить отправной точкой в процессе выработки
основных направлений проекта конкретной задачи, или же он может
использоваться организацией в качестве проверочного списка. Подчеркну
еще раз, что эти правила не являются универсальными и не могут
заменить собой размышления.
- Нацеливайте пользователя на применение абстракции данных и
объектно-ориентированного программирования.
- Постепенно переходите на новые методы, не спешите.
- Используйте возможности С++ и методы обЪектно-ориентированного
программирования только по мере надобности.
_ Добейтесь соответствия стиля проекта и программы.
- Концентрируйте внимание на проектировании компонента.
_ Используйте классы для представления понятий.
- Используйте общее наследование для представления отношений "есть".
- Используйте принадлежность для представления отношений "имеет".
- Убедитесь, что отношения использования понятны, не образуют
циклов, и что число их минимально.
- Активно ищите общность среди понятий области приложения и
реализации, и возникающие в результате более общие понятия
представляйте как базовые классы.
- Определяйте интерфейс так, чтобы открывать минимальное количество
требуемой информации:
- Используйте, всюду где это можно, частные данные и функции-члены.
- Используйте описания public или protected, чтобы отличить
запросы разработчика производных классов от запросов обычных
пользователей.
- Сведите к минимуму зависимости одного интерфейса от других.
- Поддерживайте строгую типизацию интерфейсов.
- Задавайте интерфейсы в терминах типов из области приложения.
Дополнительные правила можно найти $$11.5.