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

Для тех, кто считает пример моделирования движения транспорта экзотичным, имеет смысл сказать, что в процессе проектирования почти постоянно возникает подобный выбор между наследованием и принадлежностью. Аналогичный пример есть в $$12.2.5, где описывается свиток (scrollbar) -прокручивание информации в окне.

12.2.3 Зависимости в рамках иерархии классов.

Естественно, производный класс зависит от своих базовых классов. Гораздо реже учитывают, что обратное также может быть справедливо.

Эту мысль можно выразить таким способом: Сумасшествие наследуется, вы можете получить его от своих детей.

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

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).

12.2.4 Отношения принадлежности

Если используется отношение принадлежности, то существует два основных способа представления объекта класса 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) { }

...

Разрешая объектам содержать указатели на другие объекты, мы создаем то, что обычно называется иерархия объектов . Это альтернативный и вспомогательный способ структурирования по отношению к иерархии классов. Как было показано на примере аварийного движущегося средства в $$1 2.2.2, часто это довольно тонкий вопрос проектирования: представлять ли свойство класса как еще один базовый класс или как член класса. Потребность в переопределении следует считать указанием, что первый вариант лучше. Но если надо иметь возможность представлять некоторое свойство с помощью различных типов, то лучше остановиться на втором варианте. Например:

class XX : public X { /*...*/ }; class XXX : public X { /*...*/ };

void f()