Страница:
а окна на моем дисплее имеют самое отдаленное отношение к
приспособлениям для презентации чертежей в моей комнате.
Ь Я бы не вынес такого беспорядка у себя на экране.
Суть моделирования реальности не в покорном следовании тому,
что мы видим, а в использовании реальности как начала для проектирования,
источника вдохновения и как якоря, который удерживает, когда
стихия программирования грозит лишить нас способности
понимания своей собственной программы.
Здесь полезно предостеречь: новичкам обычно трудно "находить"
классы, но вскоре это преодолевается без каких-либо
неприятностей. Далее обычно приходит этап, когда классы и отношения
наследования между ними бесконтрольно множатся. Здесь уже
возникают проблемы, связанные со сложностью, эффективностью и
ясностью полученной программы. Далеко не каждую отдельную деталь
следует представлять отдельным классом, и далеко не каждое
отношение между классами следует представлять как отношение
наследования. Старайтесь не забывать, что цель проекта - смоделировать
систему с подходящим уровнем детализации и подходящим уровнем
абстракции. Для больших систем найти компромисс между простотой и
общностью далеко не простая задача.
Рассмотрим моделирование транспортного потока в городе, цель которого
достаточно точно определить время, требующееся, чтобы аварийные движущиеся
средства достигли пункта назначения. Очевидно, нам надо иметь
представления легковых и грузовых машин, машин скорой помощи,
всевозможных пожарных и полицейских машин, автобусов и т.п.
Поскольку всякое понятие реального мира не существует изолированно,
а соединено многочисленными связями с другими понятиями,
возникает такое отношение как наследование. Не разобравшись в понятиях
и их взаимных связях, мы не в состоянии постичь никакое отдельное
понятие. Также и модель, если не отражает отношения между
понятиями, не может адекватно представлять сами понятия. Итак, в
нашей программе нужны классы для представления понятий, но этого
недостаточно. Нам нужны способы представления отношений между классами.
Наследование является мощным способом прямого представления
иерархических отношений. В нашем примере, мы, по всей видимости,
сочли бы аварийные средства специальными движущимися средствами
и, помимо этого, выделили бы средства, представленные легковыми и
грузовыми машинами. Тогда иерархия классов приобрела бы такой вид:
движущееся средство
легковая машина аварийное средство грузовая машина
полицейская машина машина скорой помощи пожарная машина
машина с выдвижной лестницей
Здесь класс Emergency представляет всю информацию, необходимую для
моделирования аварийных движущихся средств, например: аварийная
машина может нарушать некоторые правила движения, она имеет
приоритет на перекрестках, находится под контролем диспетчера
и т.д.
На С++ это можно задать так:
class Vehicle { /*...*/ };
class Emergency { /* */ };
class Car : public Vehicle { /*...*/ };
class Truck : public Vehicle { /*...*/ };
class Police_car : public Car , public Emergency {
//...
};
class Ambulance : public Car , public Emergency {
//...
};
class Fire_engine : public Truck , Emergency {
//...
};
class Hook_and_ladder : public Fire_engine {
//...
};
Наследование - это отношение самого высокого порядка, которое прямо
представляется в С++ и используется преимущественно на ранних
этапах проектирования. Часто возникает проблема выбора: использовать
наследование для представления отношения или предпочесть ему
принадлежность. Рассмотрим другое определение понятия аварийного
средства: движущееся средство считается аварийным, если оно
несет соответствующий световой сигнал. Это позволит упростить
иерархию классов, заменив класс Emergency на член класса
Vehicle:
движущееся средство (Vehicle {eptr})
легковая машина (Car) грузовая машина (Truck)
полицейская машина (Police_car) машина скорой помощи (Ambulance)
пожарная машина (Fire_engine)
машина с выдвижной лестницей (Hook_and_ladder)
Теперь класс Emergency используется просто как член в тех классах,
которые представляют аварийные движущиеся средства:
class Emergency { /*...*/ };
class Vehicle { public: Emergency* eptr; /*...*/ };
class Car : public Vehicle { /*...*/ };
class Truck : public Vehicle { /*...*/ };
class Police_car : public Car { /*...*/ };
class Ambulance : public Car { /*...*/ };
class Fire_engine : public Truck { /*...*/ };
class Hook_and_ladder : public Fire_engine { /*...*/ };
Здесь движущееся средство считается аварийным, если Vehicle::eptr
не равно нулю. "Простые" легковые и грузовые машины инициализируются
Vehicle::eptr равным нулю, а для других Vehicle::eptr должно быть
установлено в ненулевое значение, например:
Car::Car() // конструктор Car
{
eptr = 0;
}
Police_car::Police_car() // конструктор Police_car
{
eptr = new Emergency;
}
Такие определения упрощают преобразование аварийного средства в
обычное и наоборот:
void f(Vehicle* p)
{
delete p->eptr;
p->eptr = 0; // больше нет аварийного движущегося средства
//...
p->eptr = new Emergency; // оно появилось снова
}
Так какой же вариант иерархии классов лучше? В общем случае ответ такой:
"Лучшей является программа, которая наиболее непосредственно отражает
реальный мир". Иными словами, при выборе модели мы должны стремиться
к большей ее"реальности", но с учетом неизбежных ограничений,
накладываемых требованиями простоты и эффективности. Поэтому,
несмотря на простоту преобразования обычного движущегося средства в
аварийное, второе решение представляется непрактичным.
Пожарные машины и машины скорой помощи - это
движущиеся средства специального назначения со специально
подготовленным персоналом, они действуют под управлением команд
диспетчера, требующих специального оборудования для связи. Такое
положение означает, что принадлежность к аварийным движущимся средствам -
это базовое понятие, которое для улучшения контроля типов и
применения различных программных средств должно быть прямо
представлено в программе. Если бы мы моделировали ситуацию, в которой
назначение движущихся средств не столь определенно,
скажем, ситуацию, в которой частный транспорт периодически используется
для доставки специального персонала к месту происшествия, а связь
обеспечивается с помощью портативных приемников, тогда мог бы
оказаться подходящим и другой способ моделирования системы.
Для тех, кто считает пример моделирования движения транспорта
экзотичным, имеет смысл сказать, что в процессе проектирования
почти постоянно возникает подобный выбор между наследованием
и принадлежностью. Аналогичный пример есть в $$12.2.5, где
описывается свиток (scrollbar) - прокручивание информации в окне.
Естественно, производный класс зависит от своих базовых классов.
Гораздо реже учитывают, что обратное также может быть
справедливоЬ.
Ь Эту мысль можно выразить таким способом: "Сумасшествие наследуется,
вы можете получить его от своих детей."
Если класс содержит виртуальную функцию, производные классы могут
по своему усмотрению решать, реализовывать ли часть операций этой
функции каждый раз, когда она переопределяется в производном
классе. Если член базового класса сам вызывает одну из виртуальных
функций производного класса, тогда реализация базового класса
зависит от реализаций его производных классов. Точно так же, если
класс использует защищенный член, его реализация будет зависеть от
производных классов. Рассмотрим определения:
class B {
//...
protected:
int a;
public:
virtual int f();
int g() { int x = f(); return x-a; }
};
Каков результат работы g()? Ответ существенно зависит от определения
f() в некотором производном классе. Ниже приводится вариант, при
котором g() будет возвращать 1:
class D1 : public B {
int f() { return a+1; }
};
а при нижеследующем определении g() напечатает "Hello, World" и вернет 0:
class D1 : public {
int f() { cout<<"Hello, World\n"; return a; }
};
Этот пример демонстрирует один из важнейших моментов, связанных
с виртуальными функциями. Хотя вы можете сказать, что это
глупость, и программист никогда не напишет ничего подобного.
Дело здесь в том, что виртуальная функция является частью
интерфейса с базовым классом, и что этот класс будет, по всей
видимости, использоваться без информации о его производных классах.
Следовательно, можно так описать поведение объекта базового класса,
чтобы в дальнейшем писать программы, ничего не зная о его производных
классах.
Всякий класс, который переопределяет производную функцию, должен
реализовать вариант этой функции. Например, виртуальная функция
rotate() из класса Shape вращает геометрическую фигуру, а функции
rotate() для производных классов, таких, как Circle и Triangle,
должны вращать объекты соответствующих типов, иначе будет нарушено
основное положение о классе Shape. Но о поведении класса B или его
производных классов D1 и D2 не сформулировано никаких положений,
поэтому приведенный пример и кажется неразумным. При построении
класса главное внимание следует уделять описанию ожидаемых
действий виртуальных функций.
Следует ли считать нормальной зависимость от неизвестных
(возможно еще неопределенных) производных классов? Ответ, естественно,
зависит от целей программиста. Если цель состоит в том, чтобы
изолировать класс от всяких внешних влияний и, тем самым, доказать,
что он ведет себя определенным образом, то лучше избегать
виртуальных функций и защищенных членов. Если цель состоит в том,
чтобы разработать структуру, в которую последующие программисты
(или вы сами через неделю) смогут встраивать свои программы, то именно
виртуальные функции и предлагают элегантный способ решения,
а защищенные члены могут быть полезны при его реализации.
В качестве примера рассмотрим простой шаблон типа, определяющий
буфер:
template<class T> class buffer {
// ...
void put(T);
T get();
};
Если реакция на переполнение и обращение к пустому буферу, "запаяна"
в сам класс, его применение будет ограничено. Но если функции put()
и get() обращаются к виртуальным функциям overflow() и underflow()
соответственно, то пользователь может, удовлетворяя своим
нуждам, создать буфера различных типов:
template<class T> class buffer {
//...
virtual int overflow(T);
virtual int underflow();
void put(T); // вызвать overflow(T), когда буфер полон
T get(); // вызвать underflow(T), когда буфер пуст
};
template<class T> class circular_buffer : public buffer<T> {
//...
int overflow(T); // перейти на начало буфера, если он полон
int underflow();
};
template<class T> class expanding_buffer : public buffer<T> {
//...
int overflow(T); // увеличить размер буфера, если он полон
int underflow();
};
Этот метод использовался в библиотеках потокового ввода-вывода
($$10.5.3).
Если используется отношение принадлежности, то существует два основных
способа представления объекта класса X:
[1] Описать член типа X.
[2] Описать член типа X* или X&.
Если значение указателя не будет меняться и вопросы
эффективности не волнуют, эти способы эквивалентны:
class X {
//...
public:
X(int);
//...
};
class C {
X a;
X* p;
public:
C(int i, int j) : a(i), p(new X(j)) { }
~C() { delete p; }
};
В таких ситуациях предпочтительнее непосредственное членство объекта,
как X::a в примере выше, потому что оно дает экономию
времени, памяти и количества вводимых символов. Обратитесь также
к $$12.4 и $$13.9.
Способ, использующий указатель, следует применять в тех
случаях, когда приходится перестраивать указатель на
"объект-элемент" в течении жизни "объекта-владельца". Например:
class C2 {
X* p;
public:
C(int i) : p(new X(i)) { }
~C() { delete p; }
X* change(X* q)
{
X* t = p;
p = q;
return t;
}
};
Член типа указатель может также использоваться, чтобы дать возможность
передавать "объект-элемент" в качестве параметра:
class C3 {
X* p;
public:
C(X* q) : p(q) { }
// ...
}
Разрешая объектам содержать указатели на другие объекты, мы создаем
то, что обычно называется "иерархия объектов". Это альтернативный
и вспомогательный способ структурирования по отношению к иерархии
классов. Как было показано на примере аварийного движущегося
средства в $$12.2.2, часто это довольно тонкий вопрос проектирования:
представлять ли свойство класса как еще один базовый класс
или как член класса. Потребность в переопределении следует считать
указанием, что первый вариант лучше. Но если надо иметь
возможность представлять некоторое свойство с помощью различных
типов, то лучше остановиться на втором варианте. Например:
class XX : public X { /*...*/ };
class XXX : public X { /*...*/ };
void f()
{
C3* p1 = new C3(new X); // C3 "содержит" X
C3* p2 = new C3(new XX); // C3 "содержит" XX
C3* p3 = new C3(new XXX); // C3 "содержит" XXX
//...
}
Приведенные определения нельзя смоделировать ни с помощью производного
класса C3 от X, ни с помощью C3, имеющего член типа X, поскольку
необходимо указывать точный тип члена. Это важно для классов с
виртуальными функциями, таких, например,как класс Shape ($$1.1.2.5), и
для класса абстрактного множества ($$13.3).
Заметим, что ссылки можно применять для упрощения классов,
использующих члены-указатели, если в течение жизни объекта-владельца
ссылка настроена только на один объект, например:
class C4 {
X& r;
public:
C(X& q) : r(q) { }
// ...
};
Учитывая сложность важность отношений наследования, нет ничего
удивительного в том, что часто их неправильно понимают и используют
сверх меры. Если класс D описан как общий производный от
класса B, то часто говорят, что D есть B:
class B { /* ... */ ;
class D : public B /* ... */ }; // D сорта B
Иначе это можно сформулировать так: наследование - это
отношение "есть", или, более точно для классов D и B, наследование
- это отношение D сорта B. В отличие от этого, если класс D
содержит в качестве члена другой класс B, то говорят, что
D "имеет" B:
class D { // D имеет B
// ...
public:
B b;
// ...
};
Иными словами, принадлежность - это отношение "иметь" или
для классов D и B просто: D содержит B.
Имея два класса B и D, как выбирать между наследованием и
принадлежностью? Рассмотрим классы самолет и мотор.Новички обычно
спрашивают: будет ли хорошим решением сделать класс самолет
производным от класса мотор. Это плохое решение, поскольку
самолет не "есть" мотор, самолет "имеет" мотор. Следует подойти
к этому вопросу, рассмотрев, может ли самолет "иметь" два или
больше моторов. Поскольку это представляется вполне возможным
(даже если мы имеем дело с программой, в которой все самолеты
будут с одним мотором), следует использовать принадлежность, а
не наследование. Вопрос "Может ли он иметь два..?" оказывается
удивительно полезным во многих сомнительных случаях. Как всегда,
наше изложение затрагивает неуловимую сущность программирования.
Если бы все классы было так же легко представить, как самолет и
мотор, то было бы просто избежать и тривиальных ошибок типа той,
когда самолет определяется как производное от класса мотор. Однако,
такие ошибки достаточно часты, особенно у тех, кто
считает наследование еще одним механизмом для сочетания
конструкций языка программирования. Несмотря на удобство и
лаконичность записи, которую предоставляет наследование, его
надо использовать только для выражения тех отношений,
которые четко определены в проекте. Рассмотрим определения:
class B {
public:
virtual void f();
void g();
};
class D1 { // D1 содержит B
public:
B b;
void f(); // не переопределяет b.f()
};
void h1(D1* pd)
{
B* pb = pd; // ошибка: невозможно преобразование D1* в B*
pb = &pd->b;
pb->q(); // вызов B::q
pd->q(); // ошибка: D1 не имеет член q()
pd->b.q();
pb->f(); // вызов B::f (здесь D1::f не переопределяет)
pd->f(); // вызов D1::f
}
Обратите внимание, что в этом примере нет неявного преобразования
класса к одному из его элементов, и что класс, содержащий в
качестве члена другой класс, не переопределяет виртуальные
функции этого члена. Здесь явное отличие от примера, приведенного
ниже:
class D2 : public B { // D2 есть B
public:
void f(); // переопределение B::f()
};
void h2(D2* pd)
{
B* pb = pd; // нормально: D2* неявно преобразуется в B*
pb->q(); // вызов B::q
pd->q(); // вызов B::q
pb->f(); // вызов виртуальной функции: обращение к D2::f
pd->f(); // вызов D2::f
}
Удобство записи, продемонстрированное в примере с классом D2, по
сравнению с записью в примере с классом D1, является причиной, по
которой таким наследованием злоупотребляют. Но следует помнить,
что существует определенная плата за удобство записи в виде
возросшей зависимости между B и D2 (см. $$12.2.3). В частности,
легко забыть о неявном преобразовании D2 в B. Если только такие
преобразования не относятся к семантике ваших классов, следует
избегать описания производного класса в общей части. Если класс
представляет определенное понятие, а наследование используется
как отношение "есть", то такие преобразования обычно как раз то,
что нужно.
Однако, бывают такие ситуации, когда желательно
иметь наследование, но нельзя допускать преобразования. Рассмотрим
задание класса cfield (controled field - управляемое поле), который,
помимо всего прочего, дает возможность контролировать на стадии
выполнения доступ к другому классу field. На первый взгляд кажется
совершенно правильным определить класс cfield как производный от
класса field:
class cfield : public field {
// ...
};
Это выражает тот факт, что cfield, действительно, есть сорта field,
упрощает запись функции, которая использует член части field класса
cfield, и, что самое главное, позволяет в классе cfield
переопределять виртуальные функции из field. Загвоздка здесь в том,
что преобразование cfield* к field*, встречающееся в определении
класса cfield, позволяет обойти любой контроль доступа к field:
void q(cfield* p)
{
*p = "asdf"; // обращение к field контролируется
// функцией присваивания cfield:
// p->cfield::operator=("asdf")
field* q = p; // неявное преобразование cfield* в field*
*q = "asdf"; // приехали! контроль обойден
}
Можно было бы определить класс cfield так, чтобы field был его членом,
но тогда cfield не может переопределять виртуальные функции field.
Лучшим решением здесь будет использование наследования со спецификацией
private (частное наследование):
class cfield : private field { /* ... */ }
С позиции проектирования, если не учитывать (иногда важные) вопросы
переопределения, частное наследование эквивалентно принадлежности.
В этом случае применяется метод, при котором класс определяется
в общей части как производный от абстрактного базового класса заданием
его интерфейса, а также определяется с помощью частного наследования от
конкретного класса, задающего реализацию ($$13.3). Поскольку
наследование, используемое как частное, является
спецификой реализации, и оно не отражается в типе производного класса,
то его иногда называют "наследованием по реализации", и оно
является контрастом для наследования в общей части, когда наследуется
интерфейс базового класса и допустимы неявные преобразования к
базовому типу. Последнее наследование иногда называют определением
подтипа или "интерфейсным наследованием".
Для дальнейшего обсуждения возможности выбора наследования
или принадлежности рассмотрим, как представить в диалоговой
графической системе свиток (область для прокручивания в ней
информации), и как привязать свиток к окну на экране. Потребуются
свитки двух видов: горизонтальные и вертикальные. Это можно
представить с помощью двух типов horizontal_scrollbar и
vertical_scrollbar или с помощью одного типа scrollbar, который
имеет аргумент, определяющий, является расположение вертикальным
или горизонтальным. Первое решение предполагает, что есть еще
третий тип, задающий просто свиток - scrollbar, и этот тип
является базовым классом для двух определенных свитков. Второе
решение предполагает дополнительный аргумент у типа scrollbar и
наличие значений, задающих вид свитка. Например, так:
enum orientation { horizontal, vertical };
Как только мы остановимся на одном из решений, определится
объем изменений, которые придется внести в систему. Допустим, в
этом примере нам потребуется ввести свитки третьего вида. Вначале
предполагалось, что могут быть свитки только двух видов (ведь
всякое окно имеет только два измерения), но в этом примере,
как и во многих других, возможны расширения, которые возникают
как вопросы перепроектирования. Например, может появиться
желание использовать "управляющую кнопку" (типа мыши) вместо свитков
двух видов. Такая кнопка задавала бы прокрутку в различных
направлениях в зависимости от того, в какой части окна нажал
ее пользователь. Нажатие в середине верхней строчки должно
вызывать "прокручивание вверх", нажатие в середине левого столбца -
"прокручивание влево", нажатие в левом верхнем углу -
"прокручивание вверх и влево". Такая кнопка не является
чем-то необычным, и ее можно рассматривать как уточнение понятия
свитка, которое особенно подходит для тех областей приложения,
которые связаны не с обычными текстами, а с более сложной
информацией.
Для добавления управляющей кнопки к программе, использующей
иерархию из трех свитков, требуется добавить еще один класс, но
не нужно менять программу, работающую со старыми свитками:
свиток
горизонтальный_свиток вертикальный_свиток управляющая_кнопка
Это положительная сторона "иерархического решения".
Задание ориентации свитка в качестве параметра приводит к
заданию полей типа в объектах свитка и использованию переключателей
в теле функций-членов свитка. Иными словами, перед нами обычная
дилемма: выразить данный аспект структуры системы с помощью
определений или реализовать его в операторной части программы.
Первое решение увеличивает объем статических проверок и объем
информации, над которой могут работать разные вспомогательные
средства. Второе решение откладывает проверки на стадию выполнения
и разрешает менять тела отдельных функций, не изменяя общую
структуру системы, какой она представляется с точки зрения
статического контроля или вспомогательных средств. В большинстве
случаев, предпочтительнее первое решение.
Положительной стороной решения с единым типом свитка является то,
что легко передавать информацию о виде нужного нам свитка другой
функции:
void helper(orientation oo)
{
//...
p = new scrollbar(oo);
//...
}
void me()
{
helper(horizontal);
}
Такой подход позволяет на стадии выполнения легко перенастроить свиток
на другую ориентацию. Вряд ли это очень важно в примере со свитками,
но это может оказаться существенным в похожих примерах. Суть в том,
что всегда надо делать определенный выбор, а это часто непросто.
Теперь рассмотрим как привязать свиток к окну. Если считать
window_with_scrollbar (окно_со_свитком) как нечто, что является
window и scrollbar, мы получим подобное:
class window_with_scrollbar
: public window, public scrollbar {
// ...
};
Это позволяет любому объекту типа window_with_scrollbar выступать
и как window, и как scrollbar, но от нас требуется решение
использовать только единственный тип scrollbar.
Если, с другой стороны, считать window_with_scrollbar объектом
типа window, который имеет scrollbar, мы получим такое определение:
class window_with_scrollbar : public window {
// ...
scrollbar* sb;
public:
window_with_scrollbar(scrollbar* p, /* ... */)
: window(/* ... */), sb(p)
{
// ...
}
// ...
};
Здесь мы можем использовать решение со свитками трех типов. Передача
самого свитка в качестве параметра позволяет окну (window) не
запоминать тип его свитка. Если потребуется, чтобы объект типа
window_with_scrollbar действовал как scrollbar, можно добавить
операцию преобразования:
window_with_scrollbar :: operator scrollbar&()
{
return *sb;
}
Для составления и понимания проекта часто необходимо знать,
какие классы и каким способом использует данный класс.
Такие отношения классов
на С++ выражаются неявно. Класс может использовать только те
имена, которые где-то определены, но нет такой части в программе
на С++, которая содержала бы список всех используемых имен.
Для получения такого списка необходимы
вспомогательные средства (или, при их отсутствии, внимательное
чтение). Можно следующим образом классифицировать те способы,
с помощью которых класс X может использовать класс Y:
- X использует имя Y
- X использует Y
- X вызывает функцию-член Y
- X читает член Y
- X пишет в член Y
- X создает Y
- X размещает auto или static переменную из Y
- X создает Y с помощью new
- X использует размер Y
Мы отнесли использование размера объекта к его созданию, поскольку
для этого требуется знание полного определения класса. С другой
стороны, мы выделили в отдельное отношение использование имени Y,
поскольку, указывая его в описании Y* или в описании
внешней функции, мы вовсе не нуждаемся в доступе к определению Y:
class Y; // Y - имя класса
Y* p;
extern Y f(const Y&);
Мы отделили создание Y с помощью new от случая описания
переменной, поскольку возможна такая реализация С++, при которой
для создания Y с помощью new необязательно знать
размер Y. Это может быть существенно для ограничения всех зависимостей
в проекте и сведения к минимуму перетрансляции после внесения изменений.
Язык С++ не требует, чтобы создатель классов точно определял,
какие классы и как он будет использовать. Одна из причин этого
заключена в том, что самые важные классы зависят от столь большого
количества других классов, что для придания лучшего вида программе
нужна сокращенная форма записи списка используемых классов, например,
с помощью команды #include. Другая причина в том, что классификация
этих зависимостей и, в частности, обЪединение некоторых зависимостей
не является обязанностью языка программирования. Наоборот, цели
разработчика, программиста или вспомогательного средства определяют то,
как именно следует рассматривать отношения использования. Наконец, то,
какие зависимости представляют больший интерес, может зависеть от
специфики реализации языка.
До сих пор мы обсуждали только классы, и хотя операции упоминались,
если не считать обсуждения шагов процесса развития программного
обеспечения ($$11.3.3.2), то они были на втором плане, объекты же
практически вообще не упоминались. Понять это просто: в С++
класс, а не функция или объект, является основным понятием
приспособлениям для презентации чертежей в моей комнате.
Ь Я бы не вынес такого беспорядка у себя на экране.
Суть моделирования реальности не в покорном следовании тому,
что мы видим, а в использовании реальности как начала для проектирования,
источника вдохновения и как якоря, который удерживает, когда
стихия программирования грозит лишить нас способности
понимания своей собственной программы.
Здесь полезно предостеречь: новичкам обычно трудно "находить"
классы, но вскоре это преодолевается без каких-либо
неприятностей. Далее обычно приходит этап, когда классы и отношения
наследования между ними бесконтрольно множатся. Здесь уже
возникают проблемы, связанные со сложностью, эффективностью и
ясностью полученной программы. Далеко не каждую отдельную деталь
следует представлять отдельным классом, и далеко не каждое
отношение между классами следует представлять как отношение
наследования. Старайтесь не забывать, что цель проекта - смоделировать
систему с подходящим уровнем детализации и подходящим уровнем
абстракции. Для больших систем найти компромисс между простотой и
общностью далеко не простая задача.
Рассмотрим моделирование транспортного потока в городе, цель которого
достаточно точно определить время, требующееся, чтобы аварийные движущиеся
средства достигли пункта назначения. Очевидно, нам надо иметь
представления легковых и грузовых машин, машин скорой помощи,
всевозможных пожарных и полицейских машин, автобусов и т.п.
Поскольку всякое понятие реального мира не существует изолированно,
а соединено многочисленными связями с другими понятиями,
возникает такое отношение как наследование. Не разобравшись в понятиях
и их взаимных связях, мы не в состоянии постичь никакое отдельное
понятие. Также и модель, если не отражает отношения между
понятиями, не может адекватно представлять сами понятия. Итак, в
нашей программе нужны классы для представления понятий, но этого
недостаточно. Нам нужны способы представления отношений между классами.
Наследование является мощным способом прямого представления
иерархических отношений. В нашем примере, мы, по всей видимости,
сочли бы аварийные средства специальными движущимися средствами
и, помимо этого, выделили бы средства, представленные легковыми и
грузовыми машинами. Тогда иерархия классов приобрела бы такой вид:
движущееся средство
легковая машина аварийное средство грузовая машина
полицейская машина машина скорой помощи пожарная машина
машина с выдвижной лестницей
Здесь класс Emergency представляет всю информацию, необходимую для
моделирования аварийных движущихся средств, например: аварийная
машина может нарушать некоторые правила движения, она имеет
приоритет на перекрестках, находится под контролем диспетчера
и т.д.
На С++ это можно задать так:
class Vehicle { /*...*/ };
class Emergency { /* */ };
class Car : public Vehicle { /*...*/ };
class Truck : public Vehicle { /*...*/ };
class Police_car : public Car , public Emergency {
//...
};
class Ambulance : public Car , public Emergency {
//...
};
class Fire_engine : public Truck , Emergency {
//...
};
class Hook_and_ladder : public Fire_engine {
//...
};
Наследование - это отношение самого высокого порядка, которое прямо
представляется в С++ и используется преимущественно на ранних
этапах проектирования. Часто возникает проблема выбора: использовать
наследование для представления отношения или предпочесть ему
принадлежность. Рассмотрим другое определение понятия аварийного
средства: движущееся средство считается аварийным, если оно
несет соответствующий световой сигнал. Это позволит упростить
иерархию классов, заменив класс Emergency на член класса
Vehicle:
движущееся средство (Vehicle {eptr})
легковая машина (Car) грузовая машина (Truck)
полицейская машина (Police_car) машина скорой помощи (Ambulance)
пожарная машина (Fire_engine)
машина с выдвижной лестницей (Hook_and_ladder)
Теперь класс Emergency используется просто как член в тех классах,
которые представляют аварийные движущиеся средства:
class Emergency { /*...*/ };
class Vehicle { public: Emergency* eptr; /*...*/ };
class Car : public Vehicle { /*...*/ };
class Truck : public Vehicle { /*...*/ };
class Police_car : public Car { /*...*/ };
class Ambulance : public Car { /*...*/ };
class Fire_engine : public Truck { /*...*/ };
class Hook_and_ladder : public Fire_engine { /*...*/ };
Здесь движущееся средство считается аварийным, если Vehicle::eptr
не равно нулю. "Простые" легковые и грузовые машины инициализируются
Vehicle::eptr равным нулю, а для других Vehicle::eptr должно быть
установлено в ненулевое значение, например:
Car::Car() // конструктор Car
{
eptr = 0;
}
Police_car::Police_car() // конструктор Police_car
{
eptr = new Emergency;
}
Такие определения упрощают преобразование аварийного средства в
обычное и наоборот:
void f(Vehicle* p)
{
delete p->eptr;
p->eptr = 0; // больше нет аварийного движущегося средства
//...
p->eptr = new Emergency; // оно появилось снова
}
Так какой же вариант иерархии классов лучше? В общем случае ответ такой:
"Лучшей является программа, которая наиболее непосредственно отражает
реальный мир". Иными словами, при выборе модели мы должны стремиться
к большей ее"реальности", но с учетом неизбежных ограничений,
накладываемых требованиями простоты и эффективности. Поэтому,
несмотря на простоту преобразования обычного движущегося средства в
аварийное, второе решение представляется непрактичным.
Пожарные машины и машины скорой помощи - это
движущиеся средства специального назначения со специально
подготовленным персоналом, они действуют под управлением команд
диспетчера, требующих специального оборудования для связи. Такое
положение означает, что принадлежность к аварийным движущимся средствам -
это базовое понятие, которое для улучшения контроля типов и
применения различных программных средств должно быть прямо
представлено в программе. Если бы мы моделировали ситуацию, в которой
назначение движущихся средств не столь определенно,
скажем, ситуацию, в которой частный транспорт периодически используется
для доставки специального персонала к месту происшествия, а связь
обеспечивается с помощью портативных приемников, тогда мог бы
оказаться подходящим и другой способ моделирования системы.
Для тех, кто считает пример моделирования движения транспорта
экзотичным, имеет смысл сказать, что в процессе проектирования
почти постоянно возникает подобный выбор между наследованием
и принадлежностью. Аналогичный пример есть в $$12.2.5, где
описывается свиток (scrollbar) - прокручивание информации в окне.
Естественно, производный класс зависит от своих базовых классов.
Гораздо реже учитывают, что обратное также может быть
справедливоЬ.
Ь Эту мысль можно выразить таким способом: "Сумасшествие наследуется,
вы можете получить его от своих детей."
Если класс содержит виртуальную функцию, производные классы могут
по своему усмотрению решать, реализовывать ли часть операций этой
функции каждый раз, когда она переопределяется в производном
классе. Если член базового класса сам вызывает одну из виртуальных
функций производного класса, тогда реализация базового класса
зависит от реализаций его производных классов. Точно так же, если
класс использует защищенный член, его реализация будет зависеть от
производных классов. Рассмотрим определения:
class B {
//...
protected:
int a;
public:
virtual int f();
int g() { int x = f(); return x-a; }
};
Каков результат работы g()? Ответ существенно зависит от определения
f() в некотором производном классе. Ниже приводится вариант, при
котором g() будет возвращать 1:
class D1 : public B {
int f() { return a+1; }
};
а при нижеследующем определении g() напечатает "Hello, World" и вернет 0:
class D1 : public {
int f() { cout<<"Hello, World\n"; return a; }
};
Этот пример демонстрирует один из важнейших моментов, связанных
с виртуальными функциями. Хотя вы можете сказать, что это
глупость, и программист никогда не напишет ничего подобного.
Дело здесь в том, что виртуальная функция является частью
интерфейса с базовым классом, и что этот класс будет, по всей
видимости, использоваться без информации о его производных классах.
Следовательно, можно так описать поведение объекта базового класса,
чтобы в дальнейшем писать программы, ничего не зная о его производных
классах.
Всякий класс, который переопределяет производную функцию, должен
реализовать вариант этой функции. Например, виртуальная функция
rotate() из класса Shape вращает геометрическую фигуру, а функции
rotate() для производных классов, таких, как Circle и Triangle,
должны вращать объекты соответствующих типов, иначе будет нарушено
основное положение о классе Shape. Но о поведении класса B или его
производных классов D1 и D2 не сформулировано никаких положений,
поэтому приведенный пример и кажется неразумным. При построении
класса главное внимание следует уделять описанию ожидаемых
действий виртуальных функций.
Следует ли считать нормальной зависимость от неизвестных
(возможно еще неопределенных) производных классов? Ответ, естественно,
зависит от целей программиста. Если цель состоит в том, чтобы
изолировать класс от всяких внешних влияний и, тем самым, доказать,
что он ведет себя определенным образом, то лучше избегать
виртуальных функций и защищенных членов. Если цель состоит в том,
чтобы разработать структуру, в которую последующие программисты
(или вы сами через неделю) смогут встраивать свои программы, то именно
виртуальные функции и предлагают элегантный способ решения,
а защищенные члены могут быть полезны при его реализации.
В качестве примера рассмотрим простой шаблон типа, определяющий
буфер:
template<class T> class buffer {
// ...
void put(T);
T get();
};
Если реакция на переполнение и обращение к пустому буферу, "запаяна"
в сам класс, его применение будет ограничено. Но если функции put()
и get() обращаются к виртуальным функциям overflow() и underflow()
соответственно, то пользователь может, удовлетворяя своим
нуждам, создать буфера различных типов:
template<class T> class buffer {
//...
virtual int overflow(T);
virtual int underflow();
void put(T); // вызвать overflow(T), когда буфер полон
T get(); // вызвать underflow(T), когда буфер пуст
};
template<class T> class circular_buffer : public buffer<T> {
//...
int overflow(T); // перейти на начало буфера, если он полон
int underflow();
};
template<class T> class expanding_buffer : public buffer<T> {
//...
int overflow(T); // увеличить размер буфера, если он полон
int underflow();
};
Этот метод использовался в библиотеках потокового ввода-вывода
($$10.5.3).
Если используется отношение принадлежности, то существует два основных
способа представления объекта класса X:
[1] Описать член типа X.
[2] Описать член типа X* или X&.
Если значение указателя не будет меняться и вопросы
эффективности не волнуют, эти способы эквивалентны:
class X {
//...
public:
X(int);
//...
};
class C {
X a;
X* p;
public:
C(int i, int j) : a(i), p(new X(j)) { }
~C() { delete p; }
};
В таких ситуациях предпочтительнее непосредственное членство объекта,
как X::a в примере выше, потому что оно дает экономию
времени, памяти и количества вводимых символов. Обратитесь также
к $$12.4 и $$13.9.
Способ, использующий указатель, следует применять в тех
случаях, когда приходится перестраивать указатель на
"объект-элемент" в течении жизни "объекта-владельца". Например:
class C2 {
X* p;
public:
C(int i) : p(new X(i)) { }
~C() { delete p; }
X* change(X* q)
{
X* t = p;
p = q;
return t;
}
};
Член типа указатель может также использоваться, чтобы дать возможность
передавать "объект-элемент" в качестве параметра:
class C3 {
X* p;
public:
C(X* q) : p(q) { }
// ...
}
Разрешая объектам содержать указатели на другие объекты, мы создаем
то, что обычно называется "иерархия объектов". Это альтернативный
и вспомогательный способ структурирования по отношению к иерархии
классов. Как было показано на примере аварийного движущегося
средства в $$12.2.2, часто это довольно тонкий вопрос проектирования:
представлять ли свойство класса как еще один базовый класс
или как член класса. Потребность в переопределении следует считать
указанием, что первый вариант лучше. Но если надо иметь
возможность представлять некоторое свойство с помощью различных
типов, то лучше остановиться на втором варианте. Например:
class XX : public X { /*...*/ };
class XXX : public X { /*...*/ };
void f()
{
C3* p1 = new C3(new X); // C3 "содержит" X
C3* p2 = new C3(new XX); // C3 "содержит" XX
C3* p3 = new C3(new XXX); // C3 "содержит" XXX
//...
}
Приведенные определения нельзя смоделировать ни с помощью производного
класса C3 от X, ни с помощью C3, имеющего член типа X, поскольку
необходимо указывать точный тип члена. Это важно для классов с
виртуальными функциями, таких, например,как класс Shape ($$1.1.2.5), и
для класса абстрактного множества ($$13.3).
Заметим, что ссылки можно применять для упрощения классов,
использующих члены-указатели, если в течение жизни объекта-владельца
ссылка настроена только на один объект, например:
class C4 {
X& r;
public:
C(X& q) : r(q) { }
// ...
};
Учитывая сложность важность отношений наследования, нет ничего
удивительного в том, что часто их неправильно понимают и используют
сверх меры. Если класс D описан как общий производный от
класса B, то часто говорят, что D есть B:
class B { /* ... */ ;
class D : public B /* ... */ }; // D сорта B
Иначе это можно сформулировать так: наследование - это
отношение "есть", или, более точно для классов D и B, наследование
- это отношение D сорта B. В отличие от этого, если класс D
содержит в качестве члена другой класс B, то говорят, что
D "имеет" B:
class D { // D имеет B
// ...
public:
B b;
// ...
};
Иными словами, принадлежность - это отношение "иметь" или
для классов D и B просто: D содержит B.
Имея два класса B и D, как выбирать между наследованием и
принадлежностью? Рассмотрим классы самолет и мотор.Новички обычно
спрашивают: будет ли хорошим решением сделать класс самолет
производным от класса мотор. Это плохое решение, поскольку
самолет не "есть" мотор, самолет "имеет" мотор. Следует подойти
к этому вопросу, рассмотрев, может ли самолет "иметь" два или
больше моторов. Поскольку это представляется вполне возможным
(даже если мы имеем дело с программой, в которой все самолеты
будут с одним мотором), следует использовать принадлежность, а
не наследование. Вопрос "Может ли он иметь два..?" оказывается
удивительно полезным во многих сомнительных случаях. Как всегда,
наше изложение затрагивает неуловимую сущность программирования.
Если бы все классы было так же легко представить, как самолет и
мотор, то было бы просто избежать и тривиальных ошибок типа той,
когда самолет определяется как производное от класса мотор. Однако,
такие ошибки достаточно часты, особенно у тех, кто
считает наследование еще одним механизмом для сочетания
конструкций языка программирования. Несмотря на удобство и
лаконичность записи, которую предоставляет наследование, его
надо использовать только для выражения тех отношений,
которые четко определены в проекте. Рассмотрим определения:
class B {
public:
virtual void f();
void g();
};
class D1 { // D1 содержит B
public:
B b;
void f(); // не переопределяет b.f()
};
void h1(D1* pd)
{
B* pb = pd; // ошибка: невозможно преобразование D1* в B*
pb = &pd->b;
pb->q(); // вызов B::q
pd->q(); // ошибка: D1 не имеет член q()
pd->b.q();
pb->f(); // вызов B::f (здесь D1::f не переопределяет)
pd->f(); // вызов D1::f
}
Обратите внимание, что в этом примере нет неявного преобразования
класса к одному из его элементов, и что класс, содержащий в
качестве члена другой класс, не переопределяет виртуальные
функции этого члена. Здесь явное отличие от примера, приведенного
ниже:
class D2 : public B { // D2 есть B
public:
void f(); // переопределение B::f()
};
void h2(D2* pd)
{
B* pb = pd; // нормально: D2* неявно преобразуется в B*
pb->q(); // вызов B::q
pd->q(); // вызов B::q
pb->f(); // вызов виртуальной функции: обращение к D2::f
pd->f(); // вызов D2::f
}
Удобство записи, продемонстрированное в примере с классом D2, по
сравнению с записью в примере с классом D1, является причиной, по
которой таким наследованием злоупотребляют. Но следует помнить,
что существует определенная плата за удобство записи в виде
возросшей зависимости между B и D2 (см. $$12.2.3). В частности,
легко забыть о неявном преобразовании D2 в B. Если только такие
преобразования не относятся к семантике ваших классов, следует
избегать описания производного класса в общей части. Если класс
представляет определенное понятие, а наследование используется
как отношение "есть", то такие преобразования обычно как раз то,
что нужно.
Однако, бывают такие ситуации, когда желательно
иметь наследование, но нельзя допускать преобразования. Рассмотрим
задание класса cfield (controled field - управляемое поле), который,
помимо всего прочего, дает возможность контролировать на стадии
выполнения доступ к другому классу field. На первый взгляд кажется
совершенно правильным определить класс cfield как производный от
класса field:
class cfield : public field {
// ...
};
Это выражает тот факт, что cfield, действительно, есть сорта field,
упрощает запись функции, которая использует член части field класса
cfield, и, что самое главное, позволяет в классе cfield
переопределять виртуальные функции из field. Загвоздка здесь в том,
что преобразование cfield* к field*, встречающееся в определении
класса cfield, позволяет обойти любой контроль доступа к field:
void q(cfield* p)
{
*p = "asdf"; // обращение к field контролируется
// функцией присваивания cfield:
// p->cfield::operator=("asdf")
field* q = p; // неявное преобразование cfield* в field*
*q = "asdf"; // приехали! контроль обойден
}
Можно было бы определить класс cfield так, чтобы field был его членом,
но тогда cfield не может переопределять виртуальные функции field.
Лучшим решением здесь будет использование наследования со спецификацией
private (частное наследование):
class cfield : private field { /* ... */ }
С позиции проектирования, если не учитывать (иногда важные) вопросы
переопределения, частное наследование эквивалентно принадлежности.
В этом случае применяется метод, при котором класс определяется
в общей части как производный от абстрактного базового класса заданием
его интерфейса, а также определяется с помощью частного наследования от
конкретного класса, задающего реализацию ($$13.3). Поскольку
наследование, используемое как частное, является
спецификой реализации, и оно не отражается в типе производного класса,
то его иногда называют "наследованием по реализации", и оно
является контрастом для наследования в общей части, когда наследуется
интерфейс базового класса и допустимы неявные преобразования к
базовому типу. Последнее наследование иногда называют определением
подтипа или "интерфейсным наследованием".
Для дальнейшего обсуждения возможности выбора наследования
или принадлежности рассмотрим, как представить в диалоговой
графической системе свиток (область для прокручивания в ней
информации), и как привязать свиток к окну на экране. Потребуются
свитки двух видов: горизонтальные и вертикальные. Это можно
представить с помощью двух типов horizontal_scrollbar и
vertical_scrollbar или с помощью одного типа scrollbar, который
имеет аргумент, определяющий, является расположение вертикальным
или горизонтальным. Первое решение предполагает, что есть еще
третий тип, задающий просто свиток - scrollbar, и этот тип
является базовым классом для двух определенных свитков. Второе
решение предполагает дополнительный аргумент у типа scrollbar и
наличие значений, задающих вид свитка. Например, так:
enum orientation { horizontal, vertical };
Как только мы остановимся на одном из решений, определится
объем изменений, которые придется внести в систему. Допустим, в
этом примере нам потребуется ввести свитки третьего вида. Вначале
предполагалось, что могут быть свитки только двух видов (ведь
всякое окно имеет только два измерения), но в этом примере,
как и во многих других, возможны расширения, которые возникают
как вопросы перепроектирования. Например, может появиться
желание использовать "управляющую кнопку" (типа мыши) вместо свитков
двух видов. Такая кнопка задавала бы прокрутку в различных
направлениях в зависимости от того, в какой части окна нажал
ее пользователь. Нажатие в середине верхней строчки должно
вызывать "прокручивание вверх", нажатие в середине левого столбца -
"прокручивание влево", нажатие в левом верхнем углу -
"прокручивание вверх и влево". Такая кнопка не является
чем-то необычным, и ее можно рассматривать как уточнение понятия
свитка, которое особенно подходит для тех областей приложения,
которые связаны не с обычными текстами, а с более сложной
информацией.
Для добавления управляющей кнопки к программе, использующей
иерархию из трех свитков, требуется добавить еще один класс, но
не нужно менять программу, работающую со старыми свитками:
свиток
горизонтальный_свиток вертикальный_свиток управляющая_кнопка
Это положительная сторона "иерархического решения".
Задание ориентации свитка в качестве параметра приводит к
заданию полей типа в объектах свитка и использованию переключателей
в теле функций-членов свитка. Иными словами, перед нами обычная
дилемма: выразить данный аспект структуры системы с помощью
определений или реализовать его в операторной части программы.
Первое решение увеличивает объем статических проверок и объем
информации, над которой могут работать разные вспомогательные
средства. Второе решение откладывает проверки на стадию выполнения
и разрешает менять тела отдельных функций, не изменяя общую
структуру системы, какой она представляется с точки зрения
статического контроля или вспомогательных средств. В большинстве
случаев, предпочтительнее первое решение.
Положительной стороной решения с единым типом свитка является то,
что легко передавать информацию о виде нужного нам свитка другой
функции:
void helper(orientation oo)
{
//...
p = new scrollbar(oo);
//...
}
void me()
{
helper(horizontal);
}
Такой подход позволяет на стадии выполнения легко перенастроить свиток
на другую ориентацию. Вряд ли это очень важно в примере со свитками,
но это может оказаться существенным в похожих примерах. Суть в том,
что всегда надо делать определенный выбор, а это часто непросто.
Теперь рассмотрим как привязать свиток к окну. Если считать
window_with_scrollbar (окно_со_свитком) как нечто, что является
window и scrollbar, мы получим подобное:
class window_with_scrollbar
: public window, public scrollbar {
// ...
};
Это позволяет любому объекту типа window_with_scrollbar выступать
и как window, и как scrollbar, но от нас требуется решение
использовать только единственный тип scrollbar.
Если, с другой стороны, считать window_with_scrollbar объектом
типа window, который имеет scrollbar, мы получим такое определение:
class window_with_scrollbar : public window {
// ...
scrollbar* sb;
public:
window_with_scrollbar(scrollbar* p, /* ... */)
: window(/* ... */), sb(p)
{
// ...
}
// ...
};
Здесь мы можем использовать решение со свитками трех типов. Передача
самого свитка в качестве параметра позволяет окну (window) не
запоминать тип его свитка. Если потребуется, чтобы объект типа
window_with_scrollbar действовал как scrollbar, можно добавить
операцию преобразования:
window_with_scrollbar :: operator scrollbar&()
{
return *sb;
}
Для составления и понимания проекта часто необходимо знать,
какие классы и каким способом использует данный класс.
Такие отношения классов
на С++ выражаются неявно. Класс может использовать только те
имена, которые где-то определены, но нет такой части в программе
на С++, которая содержала бы список всех используемых имен.
Для получения такого списка необходимы
вспомогательные средства (или, при их отсутствии, внимательное
чтение). Можно следующим образом классифицировать те способы,
с помощью которых класс X может использовать класс Y:
- X использует имя Y
- X использует Y
- X вызывает функцию-член Y
- X читает член Y
- X пишет в член Y
- X создает Y
- X размещает auto или static переменную из Y
- X создает Y с помощью new
- X использует размер Y
Мы отнесли использование размера объекта к его созданию, поскольку
для этого требуется знание полного определения класса. С другой
стороны, мы выделили в отдельное отношение использование имени Y,
поскольку, указывая его в описании Y* или в описании
внешней функции, мы вовсе не нуждаемся в доступе к определению Y:
class Y; // Y - имя класса
Y* p;
extern Y f(const Y&);
Мы отделили создание Y с помощью new от случая описания
переменной, поскольку возможна такая реализация С++, при которой
для создания Y с помощью new необязательно знать
размер Y. Это может быть существенно для ограничения всех зависимостей
в проекте и сведения к минимуму перетрансляции после внесения изменений.
Язык С++ не требует, чтобы создатель классов точно определял,
какие классы и как он будет использовать. Одна из причин этого
заключена в том, что самые важные классы зависят от столь большого
количества других классов, что для придания лучшего вида программе
нужна сокращенная форма записи списка используемых классов, например,
с помощью команды #include. Другая причина в том, что классификация
этих зависимостей и, в частности, обЪединение некоторых зависимостей
не является обязанностью языка программирования. Наоборот, цели
разработчика, программиста или вспомогательного средства определяют то,
как именно следует рассматривать отношения использования. Наконец, то,
какие зависимости представляют больший интерес, может зависеть от
специфики реализации языка.
До сих пор мы обсуждали только классы, и хотя операции упоминались,
если не считать обсуждения шагов процесса развития программного
обеспечения ($$11.3.3.2), то они были на втором плане, объекты же
практически вообще не упоминались. Понять это просто: в С++
класс, а не функция или объект, является основным понятием