* законченный учебник и руководство по языку

Вид материала

Подобный материал:

1 ... 26 27 28 29 30 31 32 33 34

будут с одним мотором), следует использовать принадлежность, а

не наследование. Вопрос "Может ли он иметь два..?" оказывается

удивительно полезным во многих сомнительных случаях. Как всегда,

наше изложение затрагивает неуловимую сущность программирования.

Если бы все классы было так же легко представить, как самолет и

мотор, то было бы просто избежать и тривиальных ошибок типа той,

когда самолет определяется как производное от класса мотор. Однако,

такие ошибки достаточно часты, особенно у тех, кто

считает наследование еще одним механизмом для сочетания

конструкций языка программирования. Несмотря на удобство и

лаконичность записи, которую предоставляет наследование, его

надо использовать только для выражения тех отношений,

которые четко определены в проекте. Рассмотрим определения:

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;

}

12.2.6 Отношения использования

Для составления и понимания проекта часто необходимо знать,

какие классы и каким способом использует данный класс.

Такие отношения классов

на С++ выражаются неявно. Класс может использовать только те

имена, которые где-то определены, но нет такой части в программе

на С++, которая содержала бы список всех используемых имен.

Для получения такого списка необходимы

вспомогательные средства (или, при их отсутствии, внимательное

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

с помощью которых класс 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. Другая причина в том, что классификация

этих зависимостей и, в частности, обЪединение некоторых зависимостей

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

разработчика, программиста или вспомогательного средства определяют то,

как именно следует рассматривать отношения использования. Наконец, то,

какие зависимости представляют больший интерес, может зависеть от

специфики реализации языка.

12.2.7 Отношения внутри класса

До сих пор мы обсуждали только классы, и хотя операции упоминались,

если не считать обсуждения шагов процесса развития программного

обеспечения ($$11.3.3.2), то они были на втором плане, объекты же

практически вообще не упоминались. Понять это просто: в С++

класс, а не функция или объект, является основным понятием

организации системы.

Класс может скрывать в себе всякую специфику реализации,

наравне с "грязными" приемами программирования, а иногда он

вынужден это делать. В то же время объекты большинства классов

сами образуют регулярную структуру и используются такими способами,

что их достаточно просто описать. Объект класса может быть

совокупностью других вложенных объектов (их часто называют членами),

многие из которых, в свою очередь, являются указателями или ссылками

на другие объекты. Поэтому отдельный объект можно рассматривать как

корень дерева объектов, а все входящие в него объекты как "иерархию

объектов", которая дополняет иерархию классов, рассмотренную в $$12.2.4.

Рассмотрим в качестве примера класс строк из $$7.6:

class String {

int sz;

char* p;

public:

String(const char* q);

~String();

//...

};

Объект типа String можно изобразить так:

12.2.7.1 Инварианты

Значение членов или объектов, доступных с помощью членов класса,

называется состоянием объекта (или просто значением объекта).

Главное при построении класса - это: привести объект в полностью

определенное состояние (инициализация), сохранять полностью определенное

состояние обЪекта в процессе выполнения над ним различных операций,

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

которое делает состояние объекта полностью определенным, называется

инвариантом.

Поэтому назначение инициализации - задать конкретные значения,

при которых выполняется инвариант объекта. Для каждой операции класса

предполагается, что инвариант должен иметь место перед выполнением

операции и должен сохраниться после операции. В конце работы

деструктор нарушает инвариант, уничтожая объект. Например,

конструктор 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
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 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
//...

}

Шаблон типа Assert() подражает макрокоманде assert() языка С.

Если i не находится в требуемом диапазоне, возникает особая

ситуация Bad_f_arg.

С помощью отдельной константы или константы из класса проверить

подобные утверждения или инварианты - пустяковое дело. Если же

необходимо проверить инварианты с помощью объекта, можно определить

производный класс, в котором проверяются операциями из класса, где нет

проверки, см. упр.8 в $$13.11.

Для классов с более сложными операциями расходы на проверки могут

быть значительны, поэтому проверки можно оставить только для "поимки"

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

мере несколько проверок даже в очень хорошо отлаженной программе.

При всех условиях сам факт определения инвариантов и использования

их при отладке дает неоценимую помощь для получения правильной

программы и, что более важно, делает понятия, представленные

классами, более регулярными и строго определенными. Дело в том, что

когда вы создаете инварианты, то рассматриваете класс с другой

Blog

* законченный учебник и руководство по языку