| Меню сайта |
|
 |
| Категория |
|
|
| Развлечение |
|
|
| ON - LINE |
|
|
| Опрос |
|
|
| Оbserver Ward |
Онлайн всего: 1 Гостей: 1 Пользователей: 0
|
|
| Друзья сайта |
|
|
| Hаша кнопка |
Для обмена банерами , наша кнопка для размещения у вас на сайте
|
|
|
18. Множественное и виртуальное наследование (1)
18. Множественное и виртуальное наследование
В большинстве реальных приложений на C++ используется открытое наследование от одного базового класса. Можно предположить, что и в наших программах оно в основном будет применяться именно так. Но иногда одиночного наследования не хватает, потому что с его помощью либо нельзя адекватно смоделировать абстракцию предметной области, либо получающаяся модель чересчур сложна и неинтуитивна. В таких случаях следует предпочесть множественное наследование или его частный случай – виртуальное наследование. Их поддержка, имеющаяся в C++, – основная тема настоящей главы.
18.1. Готовим сцену
Прежде чем детально описывать множественное и виртуальное наследование, покажем, зачем оно нужно. Наш первый пример взят из области трехмерной компьютерной графики. Но сначала познакомимся с предметной областью.
В компьютере сцена представляется графом сцены, который содержит информацию о геометрии (трехмерные модели), один или более источников освещения (иначе сцена будет погружена во тьму), камеру (без нее мы не можем смотреть на сцену) и несколько трансформационных узлов, с помощью которых позиционируются элементы.
Процесс применения источников освещения и камеры к геометрической модели для получения двумерного изображения, отображаемого на дисплее, называется рендерингом. В алгоритме рендеринга учитываются два основных аспекта: природа источника освещения сцены и свойства материалов поверхностей объектов, такие, как цвет, шероховатость и прозрачность. Ясно, что перышки на белоснежных крыльях феи выглядят совершенно не так, как капающие из ее глаз слезы, хотя те и другие освещены одним и тем же серебристым светом.
Добавление объектов к сцене, их перемещение, игра с источниками освещения и геометрией – работа компьютерного художника. Наша задача – предоставить интерактивную поддержку для манипуляций с графом сцены на экране. Предположим, что в текущей версии своего инструмента мы решили воспользоваться каркасом приложений Open Inventor для C++ (см. [WERNECKE94]), но с помощью подтипизации расширили его, создав собственные абстракции нужных нам классов. Например, Open Inventor располагает тремя встроенными источниками освещения, производными от абстрактного базового класса SoLight:
class SoSpotLight : public SoLight { ... }
class SoPointLight : public SoLight { ... }
class SoDirectionalLight : public SoLight { ... }
Префикс So служит для того, чтобы дать уникальные имена сущностям, которые в области компьютерной графики весьма распространены (данный каркас приложений проектировался еще до появления пространств имен). Точечный источник (point light) – это источник света, излучающий, как солнце, во всех направлениях. Направленный источник (directional light) – источник света, излучающий в одном направлении. Прожектор (spotlight) – источник, испускающий узконаправленный конический пучок, как обычный театральный прожектор.
По умолчанию Open Inventor осуществляет рендеринг графа сцены на экране с помощью библиотеки OpenGL (см. [NEIDER93]). Для интерактивного отображения этого достаточно, но почти все изображения, сгенерированные для киноиндустрии, сделаны с помощью средства RenderMan (см. [UPSTILL90]). Чтобы добавить поддержку такого алгоритма рендеринга мы, в частности, должны реализовать собственные специальные подтипы источников освещения:
class RiSpotLight : public SoSpotLight { ... }
class RiPointLight : public SoPointLight { ... }
class RiDirectionalLight : public SoDirectionalLight { ... }
Новые подтипы содержат дополнительную информацию, необходимую для рендеринга с помощью RenderMan. При этом базовые классы Open Inventor по-прежнему позволяют выполнять рендеринг с помощью OpenGL. Неприятности начинаются, когда возникает необходимость расширить поддержку теней.
В RenderMan направленный источник и прожектор поддерживают отбрасывание тени (поэтому мы называем их источниками освещения, дающими тень, – SCLS), а точечный – нет. Общий алгоритм требует, чтобы мы обошли все источники освещения на сцене и составили карту теней для каждого включенного SCLS. Проблема в том, что источники освещения хранятся в графе сцены как полиморфные объекты класса SoLight. Хотя мы можем инкапсулировать общие данные и необходимые операции в класс SCLS, непонятно, как включить его в существующую иерархию классов Open Inventor.
В поддереве с корнем SoLight в иерархии Open Inventor нет такого класса, из которого можно было бы произвести с помощью одиночного наследования класс SCLS так, чтобы в дальнейшем уже от него произвести SdRiSpotLight и SdRiDirectionalLight. Если не пользоваться множественным наследованием, лучшее, что можно сделать, – это сравнить член класса SCLS с каждым возможным типом SCLS-источника и вызвать соответствующую операцию:
SoLight *plight = next_scene_light();
if ( RiDirectionalLight *pdilite =
dynamic_cast<RiDirectionalLight*>( plight ))
pdilite->scls.cast_shadow_map();
else
if ( RiSpotLight *pslite =
dynamic_cast<RiSpotLight*>( plight ))
pslite->scls.cast_shadow_map();
// и так далее
(Оператор dynamic_cast – это часть механизма идентификации типов во время выполнения (RTTI). Он позволяет опросить тип объекта, адресованного полиморфным указателем или ссылкой. Подробно RTTI будет обсуждаться в главе 19.)
Пользуясь множественным наследованием, мы можем инкапсулировать подтипы SCLS, защитив наш код от изменений при добавлении или удалении источника освещения (см. рис. 18.1).
RiDirectionalLight :
public SoDirectionalLight, public SCLS { ... };
class RiSpotLight :
public SoSpotLight, public SCLS { ... };
// ...
SoLight *plight = next_scene_light();
if ( SCLS *pscls = dynamic_cast<SCLS*>(plight))
pscls->cast_shadow_map();
Это решение несовершенно. Если бы у нас был доступ к исходным текстам Open Inventor, то можно было бы избежать множественного наследования, добавив к SoLight член-указатель на SCLS и поддержку операции cast_shadow_map():
class SoLight : public SoNode {
public:
void cast_shadow_map()
{ if ( _scls ) _scls->cast_shadow_map(); }
// ...
protected:
SCLS *_scls;
};
// ...
SdSoLight *plight = next_scene_light();
plight-> cast_shadow_map();
Самое распространенное приложение, где используется множественное (и виртуальное) наследование, – это потоковая библиотека ввода/вывода в стандартном C++. Два основных видимых пользователю класса этой библиотеки – istream (для ввода) и ostream (для вывода). В число их общих атрибутов входят:
* информация о форматировании (представляется ли целое число в десятичной, восьмеричной или шестнадцатеричной системе счисления, число с плавающей точкой – в нотации с фиксированной точкой или в научной нотации и т.д.);
* информация о состоянии (находится ли потоковый объект в нормальном или ошибочном состоянии и т.д.);
* информация о параметрах локализации (отображается ли в начале даты день или месяц и т.д.);
* буфер, где хранятся данные, которые нужно прочитать или записать.
Эти общие атрибуты вынесены в абстрактный базовый класс ios, для которого istream и ostream являются производными.
Класс iostream – наш второй пример множественного наследования. Он предоставляет поддержку для чтения и записи в один и тот же файл; его предками являются классы istream и ostream. К сожалению, по умолчанию он также унаследует два различных экземпляра базового класса ios, а нам это не нужно.
Виртуальное наследование решает проблему наследования нескольких экземпляров базового класса, когда нужен только один разделяемый экземпляр. Упрощенная иерархия iostream изображена на рис. 18.2.
Рис. 18.2. Иерархия виртуального наследования iostream (упрощенная)
Еще один реальный пример виртуального и множественного наследования дают распределенные объектные вычисления. Подробное рассмотрение этой темы см. в серии статей Дугласа Шмидта (Douglas Schmidt) и Стива Виноски (Steve Vinoski) в [LIPPMAN96b].
В данной главе мы рассмотрим использование и поведение механизмов виртуального и множественного наследования. В другой нашей книге, "Inside the C++ Object Model", описаны более сложные вопросы производительности и дизайна этого аспекта языка.
Для последующего обсуждения мы выбрали иерархию животных в зоопарке. Наши животные существуют на разных уровнях абстракции. Есть, конечно, особи, имеющие свои имена: Линь-Линь, Маугли или Балу. Каждое животное принадлежит к какому-то виду; скажем, Линь-Линь – это гигантская панда. Виды в свою очередь входят в семейства. Так, гигантская панда – член семейства медведей, хотя, как мы увидим в разделе 18.5, по этому поводу в зоологии долго велись бурные дискуссии. Каждое семейство – член животного мира, в нашем случае ограниченного территорией зоопарка.
На каждом уровне абстракции имеются данные и операции, необходимые для поддержки все более и более широкого круга пользователей. Например, абстрактный класс ZooAnimal хранит информацию, общую для всех животных в зоопарке, и предоставляет открытый интерфейс для всех возможных запросов.
Помимо классов, описывающих животных, есть и вспомогательные классы, инкапсулирующие различные абстракции иного рода, например "животные, находящиеся под угрозой вымирания". Наша реализация класса Panda множественно наследует от Bear (медведь) и Endangered (вымирающие).
18.2. Множественное наследование
Для поддержки множественного наследования синтаксис списка базовых классов
class Bear : public ZooAnimal { ... };
расширяется: допускается наличие нескольких базовых классов, разделенных запятыми:
class Panda : public Bear, public Endangered { ... };
Для каждого из перечисленных базовых классов должен быть указан уровень доступа: public, protected или private. Как и при одиночном наследовании, множественно наследовать можно только классу, определение которого уже встречалось ранее.
Язык не накладывает никаких ограничений на число базовых классов, которым может наследовать производный. На практике чаще всего встречается два класса, один из которых представляет открытый абстрактный интерфейс, а второй – закрытую реализацию (хотя ни один из рассмотренных выше примеров этой модели не следует). Производные классы, наследующие от трех или более базовых, – это пример такого стиля проектирования, когда каждый базовый класс представляет одну грань полного интерфейса производного.
В случае множественного наследования объект производного класса содержит по одному подобъекту каждого из своих базовых (см. раздел 17.3). Например, когда мы пишем
Panda ying_yang;
то объект ying_yang будет состоять из подобъекта класса Bear (который в свою очередь содержит подобъект ZooAnimal), подобъекта Endangered и нестатических членов, объявленных в самом классе Panda, если таковые есть (см. рис. 18.3).
Рис. 18.3. Иерархия множественного наследования класса Panda
Конструкторы базовых классов вызываются в порядке объявления в списке базовых классов. Например, для ying_yang эта последовательность такова: конструктор Bear (но поскольку класс Bear – производный от ZooAnimal, то сначала вызывается конструктор ZooAnimal), затем конструктор Endangered и в самом конце конструктор Panda.
Как отмечалось в разделе 17.4, на порядок вызова не влияет ни наличие базовых классов в списке инициализации членов, ни порядок их перечисления. Иными словами, если бы конструктор Bear вызывался неявно и потому не был бы упомянут в списке инициализации членов, как в следующем примере:
// конструктор по умолчанию класса Bear вызывается до
// конструктора класса Endangered с двумя аргументами ...
Panda::Panda()
: Endangered( Endangered::environment,
Endangered::critical )
{ ... }
то все равно конструктор по умолчанию Bear был бы вызван раньше, чем явно заданный в списке конструктор класса Endangered с двумя аргументами.
Порядок вызова деструкторов всегда противоположен порядку вызова конструкторов. В нашем примере деструкторы вызываются в такой последовательности: ~Panda(), ~Endangered(), ~Bear(), ~ZooAnimal().
В разделе 17.3 уже говорилось, что в случае одиночного наследования к открытым и защищенным членам базового класса можно обращаться напрямую (не квалифицируя имя члена именем его класса), как если бы они были членами производного класса. То же самое справедливо и для множественного наследования. Однако при этом можно унаследовать одноименные члены из двух или более базовых классов. В таком случае прямое обращение оказывается неоднозначным и приводит к ошибке компиляции.
Однако такую ошибку вызывает не потенциальная неоднозначность неквалифицированного доступа к одному из двух одноименных членов, а лишь попытка фактического обращения к нему (см. раздел 17.4). Например, если в обоих классах Bear и Endangered определена функция-член print(), то инструкция
ying_yang.print( cout );
приводит к ошибке компиляции, даже если у двух унаследованных функций-членов разные списки параметров.
Error: ying_yang.print( cout ) -- ambiguous, one of
Bear::print( ostream& )
Endangered::print( ostream&, int )
Ошибка: ying_yang.print( cout ) -- неоднозначно, одна из
Bear::print( ostream& )
Endangered::print( ostream&, int )
Причина в том, что унаследованные функции-члены не образуют множество перегруженных функций внутри производного класса (см. раздел 17.3). Поэтому print() разрешается только по имени, а не по типам фактических аргументов. (О том, как производится разрешение, мы поговорим в разделе 18.4.)
В случае одиночного наследования указатель, ссылка или объект производного класса при необходимости автоматически преобразуются в указатель, ссылку или объект базового класса, которому открыто наследует производный. Это остается верным и для множественного наследования. Так, указатель, ссылку или сам объект класса Panda можно преобразовать в указатель, ссылку или объект ZooAnimal, Bear или Endangered:
extern void display( const Bear& );
extern void highlight( const Endangered& );
Panda ying_yang;
display( ying_yang ); // i?aaeeuii
highlight( ying_yang ); // i?aaeeuii
extern ostream&
operator<<( ostream&, const ZooAnimal& );
cout << ying_yang << endl; // правильно
Однако вероятность неоднозначных преобразований при множественном наследовании намного выше. Рассмотрим, к примеру, две функции:
extern void display( const Bear& );
extern void display( const Endangered& );
Неквалифицированный вызов display() для объекта класса Panda
Panda ying_yang;
display( ying_yang ); // ошибка: неоднозначность
приводит к ошибке компиляции:
Error: display( ying_yang ) -- ambiguous, one of
display( const Bear& );
display( const Endangered& );
Ошибка: display( ying_yang ) -- неоднозначно, одна из
display( const Bear& );
display( const Endangered& );
Компилятор не может различить два непосредственных базовых класса с точки зрения преобразования производного. Равным образом применимы обе трансформации. (Мы покажем способ разрешения этого конфликта в разделе 18.4.)
Чтобы понять, какое влияние оказывает множественное наследование на механизм виртуальных функций, определим их набор в каждом из непосредственных базовых классов Panda. (Виртуальные функции введены в разделе 17.2 и подробно обсуждались в разделе 17.5.)
class Bear : public ZooAnimal {
public:
virtual ~Bear();
virtual ostream& print( ostream& ) const;
virtual string isA() const;
// ...
};
class Endangered {
public:
virtual ~Endangered();
virtual ostream& print( ostream& ) const;
virtual void highlight() const;
// ...
};
Теперь определим в классе Panda собственный экземпляр print(), собственный деструктор и еще одну виртуальную функцию cuddle():
class Panda : public Bear, public Endangered
{
public:
virtual ~Panda();
virtual ostream& print( ostream& ) const;
virtual void cuddle();
// ...
};
Множество виртуальных функций, которые можно напрямую вызывать для объекта Panda, представлено в табл. 18.1.
Таблица 18.1. Виртуальные функции для класса Panda
Имя виртуальной функции Активный экземпляр
деструктор Panda::~Panda()
print(ostream&) const Panda::print(ostream&)
isA() const Bear::isA()
highlight() const Endangered::highlight()
cuddle() Panda::cuddle()
Когда ссылка или указатель на объект Bear или ZooAnimal инициализируется адресом объекта Panda или ему присваивается такой адрес, то части интерфейса, связанные с классами Panda и Endangered, становятся недоступны:
Bear *pb = new Panda;
pb->print( cout ); // i?aaeeuii: Panda::print(ostream&)
pb->isA(); // i?aaeeuii: Bear::isA()
pb->cuddle(); // ioeaea: yoi ia ?anou eioa?oaena Bear
pb->highlight(); // ioeaea: yoi ia ?anou eioa?oaena Bear
delete pb; // правильно: Panda::~Panda()
(Обратите внимание, что если бы объекту класса Panda был присвоен указатель на ZooAnimal, то все показанные выше вызовы разрешались бы так же.)
Аналогично, если ссылка или указатель на объект Endangered инициализируется адресом объекта Panda или ему присваивается такой адрес, то части интерфейса, связанные с классами Panda и Bear, становятся недоступными:
Endangered *pe = new Panda;
pe->print( cout ); // правильно: Panda::print(ostream&)
// ioeaea: yoi ia ?anou eioa?oaena Endangered
pe->cuddle();
pe->highlight(); // правильно: Endangered::highlight()
delete pe; // правильно: Panda::~Panda()
Обработка виртуального деструктора выполняется правильно независимо от типа указателя, через который мы уничтожаем объект. Например, во всех четырех инструкциях порядок вызова деструкторов один и тот же – обратный порядку вызова конструкторов:
// ZooAnimal *pz = new Panda;
delete pz;
// Bear *pb = new Panda;
delete pb;
// Panda *pp = new Panda;
delete pp;
// Endangered *pe = new Panda;
delete pe;
Деструктор класса Panda вызывается с помощью механизма виртуализации. После его выполнения по очереди статически вызываются деструкторы Endangered и Bear, а в самом конце – ZooAnimal.
Почленная инициализация и присваивание объекту производного класса, наследующего нескольким базовым, ведут себя точно так же, как и при одиночном наследовании (см. раздел 17.6). Например, для нашего объявления класса Panda
class Panda : public Bear, public Endangered
{ ... };
в результате почленной инициализации объекта ling_ling
Panda yin_yang;
Panda ling_ling = yin_yang;
вызывается копирующий конструктор класса Bear (но, так как Bear производный от ZooAnimal, сначала выполняется копирующий конструктор класса ZooAnimal), затем – класса Endangered и только потом – класса Panda. Почленное присваивание ведет себя аналогично.
Упражнение 18.1
Какие из следующих объявлений ошибочны? Почему?
(a) class CADVehicle : public CAD, Vehicle { ... };
(b) class DoublyLinkedList:
public List, public List { ... };
(c) class iostream:
private istream, private ostream { ... };
Упражнение 18.2
Дана иерархия, в каждом классе которой определен конструктор по умолчанию:
class A { ... };
class B : public A { ... };
class C : public B { ... };
class X { ... };
class Y { ... };
class Z : public X, public Y { ... };
class MI : public C, public Z { ... };
Каков порядок вызова конструкторов в таком определении:
MI mi;
Упражнение 18.3
Дана иерархия, в каждом классе которой определен конструктор по умолчанию:
class X { ... };
class A { ... };
class B : public A { ... };
class C : private B { ... };
class D : public X, public C { ... };
Какие из следующих преобразований недопустимы:
D *pd = new D;
(a) X *px = pd; (c) B *pb = pd;
(b) A *pa = pd; (d) C *pc = pd;
Упражнение 18.4
Дана иерархия классов, обладающая приведенным ниже набором виртуальных функций:
class Base {
public:
virtual ~Base();
virtual ostream& print();
virtual void debug();
virtual void readOn();
virtual void writeOn();
// ...
};
class Derived1 : virtual public Base {
public:
virtual ~Derived1();
virtual void writeOn();
// ...
};
class Derived2 : virtual public Base {
public:
virtual ~Derived2();
virtual void readOn();
// ...
};
class MI : public Derived1, public Derived2 {
public:
virtual ~MI();
virtual ostream& print();
virtual void debug();
// ...
};
Какой экземпляр виртуальной функции вызывается в каждом из следующих случаев:
Base *pb = new MI;
(a) pb->print(); (c) pb->readOn(); (e) pb->log();
(b) pb->debug(); (d) pb->writeOn(); (f) delete pb;
Упражнение 18.5
На примере иерархии классов из упражнения 18.4 определите, какие виртуальные функции активны при вызове через pd1 и pd2:
(a) Derived1 *pd1 new MI;
(b) MI obj;
Derived2 d2 = obj;
18.3. Открытое, закрытое и защищенное наследование
Открытое наследование называется еще наследованием типа. Производный класс в этом случае является подтипом базового; он замещает реализации всех функций-членов, специфичных для типа базового класса, и наследует общие для типа и подтипа функции. Можно сказать, что производный класс служит примером отношения "ЯВЛЯЕТСЯ", т.е. предоставляет специализацию более общего базового класса. Медведь (Bear) является животным из зоопарка (ZooAnimal); аудиокнига (AudioBook) является предметом, выдаваемым читателям (LibraryLendingMaterial). Мы говорим, что Bear – это подтип ZooAnimal, равно как и Panda. Аналогично AudioBook – подтип LibBook (библиотечная книга), а оба они – подтипы LibraryLendingMaterial. В любом месте программы, где ожидается базовый тип, можно вместо него подставить открыто унаследованный от него подтип, и программа будет продолжать работать правильно (при условии, конечно, что подтип реализован корректно). Во всех приведенных выше примерах демонстрировалось именно наследование типа.
Закрытое наследование называют также наследованием реализации. Производный класс напрямую не поддерживает открытый интерфейс базового, но пользуется его реализацией, предоставляя свой собственный открытый интерфейс.
Чтобы показать, какие здесь возникают вопросы, реализуем класс PeekbackStack, который поддерживает выборку из стека с помощью метода peekback():
bool
PeekbackStack::
peekback( int index, type &value ) { ... }
где value содержит элемент в позиции index, если peekback() вернула true. Если же peekback() возвращает false, то заданная аргументом index позиция некорректна и в value помещается элемент из вершины стека.
В реализации PeekbackStack возможны два типа ошибок:
* реализация абстракции PeekbackStack: некорректная реализация поведения класса;
* реализация представления данных: неправильное управление выделением и освобождением памяти, копированием объектов из стека и т.п.
Обычно стек реализуется либо как массив, либо как связанный список элементов (в стандартной библиотеке по умолчанию это делается на базе двусторонней очереди, хотя вместо нее можно использовать вектор, см. главу 6). Хотелось бы иметь гарантированно правильную (или, по крайней мере, хорошо протестированную и поддерживаемую) реализацию массива или списка, чтобы использовать ее в нашем классе PeekbackStack. Если она есть, то можно сосредоточиться на правильности поведения стека.
У нас есть класс IntArray, представленный в разделе 2.3 (мы временно откажемся от применения класса deque из стандартной библиотеки и от поддержки элементов, имеющих отличный от int тип). Вопрос, таким образом, заключается в том, как лучше всего воспользоваться классом IntArray в нашей реализации PeekbackStack. Можно задействовать механизм наследования. (Отметим, что для этого нам придется модифицировать IntArray, сделав его члены защищенными, а не закрытыми.) Реализация выглядела бы так:
#include "IntArray.h"
class PeekbackStack : public IntArray {
private:
const int static bos = -1;
public:
explicit PeekbackStack( int size )
: IntArray( size ), _top( bos ) {}
bool empty() const { return _top == bos; }
bool full() const { return _top == size()-1; }
int top() const { return _top; }
int pop() {
if ( empty() )
/* ia?aaioaou ioeaeo */ ;
return _ia[ _top-- ];
}
void push( int value ) {
if ( full() )
/* ia?aaioaou ioeaeo */ ;
_ia[ ++_top ] = value;
}
bool peekback( int index, int &value ) const;
private:
int _top;
};
inline bool
PeekbackStack::
peekback( int index, int &value ) const
{
if ( empty() )
/* ia?aaioaou ioeaeo */ ;
if ( index < 0 || index > _top )
{
value = _ia[ _top ];
return false;
}
value = _ia[ index ];
return true;
}
К сожалению, программа, которая работает с нашим новым классом PeekbackStack, может неправильно использовать открытый интерфейс базового IntArray:
extern void swap( IntArray&, int, int );
PeekbackStack is( 1024 );
// iai?aaaeaaiiia ioeai?iia eniieuciaaiea PeekbackStack
swap(is, i, j);
is.sort();
is[0] = is[512];
Абстракция PeekbackStack должна обеспечить доступ к элементам стека по принципу "последним пришел, первым ушел". Однако наличие дополнительного интерфейса IntArray не позволяет гарантировать такое поведение.
Проблема в том, что открытое наследование описывается как отношение "ЯВЛЯЕТСЯ". Но PeekbackStack не является разновидностью массива IntArray, а лишь включает его как часть своей реализации. Открытый интерфейс IntArray не должен входить в открытый интерфейс PeekbackStack.
Закрытое наследование от базового класса представляет собой вид наследования, который нельзя описать в терминах подтипов. В производном классе открытый интерфейс базового становится закрытым. Все показанные выше примеры использования объекта PeekbackStack становятся допустимыми только внутри функций-членов и друзей производного класса.
В приведенном ранее определении PeekbackStack достаточно заменить слово public в списке базовых классов на private. Внутри же самого определения класса public и private следует оставить на своих местах:
class PeekbackStack : private IntArray { ... };
18.3.1. Наследование и композиция
Реализация класса PeekbackStack с помощью закрытого наследования от IntArray работает, но необходимо ли это? Помогло ли нам наследование в данном случае? Нет.
Открытое наследование – это мощный механизм для поддержки отношения "ЯВЛЯЕТСЯ". Однако реализация PeekbackStack по отношению к IntArray – пример отношения "СОДЕРЖИТ". Класс PeekbackStack содержит класс IntArray как часть своей реализации. Отношение "СОДЕРЖИТ", как правило, лучше поддерживается с помощью композиции, а не наследования. Для ее реализации надо один класс сделать членом другого. В нашем случае объект IntArray делается членом PeekbackStack. Вот реализация PeekbackStack на основе композиции:
class PeekbackStack {
private:
const int static bos = -1;
public:
explicit PeekbackStack( int size ) :
stack( size ), _top( bos ) {}
bool empty() const { return _top == bos; }
bool full() const { return _top == size()-1; }
int top() const { return _top; }
int pop() {
if ( empty() )
/* обработать ошибку */ ;
return stack[ _top-- ];
}
void push( int value ) {
if ( full() )
/* обработать ошибку */ ;
stack[ ++_top ] = value;
}
bool peekback( int index, int &value ) const;
private:
int _top;
IntArray stack;
};
inline bool
PeekbackStack::
peekback( int index, int &value ) const
{
if ( empty() )
/* обработать ошибку */ ;
if ( index < 0 || index > _top )
{
value = stack[ _top ];
return false;
}
value = stack[ index ];
return true;
}
Решая, следует ли использовать при проектировании класса с отношением "СОДЕРЖИТ" композицию или закрытое наследование, можно руководствоваться такими соображениями:
* если мы хотим заместить какие-либо виртуальные функции базового класса, то должны закрыто наследовать ему;
* если мы хотим разрешить нашему классу ссылаться на класс из иерархии типов, то должны использовать композицию по ссылке (мы подробно расскажем о ней в разделе 18.3.4);
* если, как в случае с классом PeekbackStack, мы хотим воспользоваться готовой реализацией, то композиция по значению предпочтительнее наследования. Если требуется отложенное выделение памяти для объекта, то следует выбрать композицию по ссылке (с помощью указателя).
18.3.2. Открытие отдельных членов
Когда мы применили закрытое наследование класса PeekbackStack от IntArray, то все защищенные и открытые члены IntArray стали закрытыми членами PeekbackStack. Было бы полезно, если бы пользователи PeekbackStack могли узнать размер стека с помощью такой инструкции:
is.size();
Разработчик способен оградить некоторые члены базового класса от эффектов неоткрытого наследования. Вот как, к примеру, открывается функция-член size() класса IntArray:
class PeekbackStack : private IntArray {
public:
// сохранить открытый уровень доступа
using IntArray::size;
// ...
};
Еще одна причина для открытия отдельных членов заключается в том, что иногда необходимо разрешить доступ к защищенным членам закрыто унаследованного базового класса при последующем наследовании. Предположим, что пользователям нужен подтип стека PeekbackStack, который может динамически расти. Для этого классу, производному от PeekbackStack, понадобится доступ к защищенным элементам ia и _size класса IntArray:
template <class Type>
class PeekbackStack : private IntArray {
public:
using intArray::size;
// ...
protected:
using intArray::size;
using intArray::ia;
// ...
};
Производный класс может лишь вернуть унаследованному члену исходный уровень доступа, но не повысить или понизить его по сравнению с указанным в базовом классе.
На практике множественное наследование очень часто применяется для того, чтобы унаследовать открытый интерфейс одного класса и закрытую реализацию другого. Например, в библиотеку классов Booch Components включена следующая реализация растущей очереди Queue (см. также статью Майкла Вило (Michaeel Vilot) и Грейди Буча (Grady Booch) в [LIPPMAN96b]):
template < class item, class container >
class Unbounded_Queue:
private Simple_List<item >, // ?aaeecaoey
public Queue< item > // eioa?oaen
{ ... }
18.3.3. Защищенное наследование
Третья форма наследования – это защищенное наследование. В таком случае все открытые члены базового класса становятся в производном классе защищенными, т.е. доступными из его дальнейших наследников, но не из любого места программы вне иерархии классов. Например, если бы нужно было унаследовать PeekbackStack от Stack, то закрытое наследование
// увы: при этом не поддерживается дальнейшее наследование
// PeekbackStack: все члены IntArray теперь закрыты
class Stack : private IntArray { ... }
было бы чересчур ограничительным, поскольку закрытие членов IntArray в классе Stack делает невозможным их последующее наследование. Для того чтобы поддержать наследование вида:
class PeekbackStack : public Stack { ... };
класс Stack должен наследовать IntArray защищенно:
class Stack : protected IntArray { ... };
18.3.4. Композиция объектов
Есть две формы композиции объектов:
* композиция по значению, когда членом одного класса объявляется сам объект другого класса. Мы показывали это в исправленной реализации PeekbackStack;
* композиция по ссылке, когда членом одного класса является указатель или ссылка на объект другого класса.
Композиция по значению обеспечивает автоматическое управление временем жизни объекта и семантику копирования. Кроме того, прямой доступ к объекту оказывается более эффективным. А в каких случаях следует предпочесть композицию по ссылке?
Предположим, что мы решили с помощью композиции представить класс Endangered. Надо ли определить его объект непосредственно внутри ZooAnimal или сослаться на него с помощью указателя или ссылки? Сначала выясним, все ли объекты ZooAnimal обладают этой характеристикой, а если нет, то может ли она изменяться с течением времени (допустимо ли добавлять или удалять эту характеристику).
Если ответ на первый вопрос положительный, то, как правило, лучше применить композицию по значению. (Как правило, но не всегда, поскольку с точки зрения эффективности включение больших объектов не оптимально, особенно когда они часто копируются. В таких случаях композиция по ссылке позволит обойтись без ненужных копирований, если применять при этом подсчет ссылок и технику, называемую копированием при записи. Увеличение эффективности, правда, достигается за счет усложнения управления объектом. Обсуждение этой техники не вошло в наш вводный курс; тем, кому это интересно, рекомендуем прочитать книгу [KOENIG97], главы 6 и 7.)
Если же оказывается, что только некоторые объекты класса ZooAnimal обладают указанной характеристикой, то лучшим вариантом будет композиция по ссылке (скажем, в примере с зоопарком не имеет смысла включать в процветающие виды большой объект, описывающий виды вымирающие).
Поскольку объекта Endangered может и не существовать, то представлять его надо указателем, а не ссылкой. (Предполагается, что нулевой указатель не адресует объект. Ссылка же всегда должна именовать определенный объект. В разделе 3.6 это различие объяснялось более подробно.)
Если ответ на второй вопрос положительный, то необходимо задать функции, позволяющие вставить и удалить объект Endangered во время выполнения.
В нашем примере лишь небольшая часть всего множества животных в зоопарке находится под угрозой вымирания. Кроме того, по крайней мере теоретически, данная характеристика не является постоянной, и, допустим, в один прекрасный день это может перестать грозить панде.
class ZooAnimal {
public:
// ...
const Endangered* Endangered() const;
void addEndangered( Endangered* );
void removeEndangered();
// ...
protected:
Endangered *_endangered;
// ...
};
Если предполагается, что наше приложение будет работать на разных платформах, то полезно инкапсулировать всю платформенно-зависимую информацию в иерархию абстрактных классов, чтобы запрограммировать платформенно-независимый интерфейс. Например, для вывода объекта ZooAnimal на дисплей UNIX-машины и ПК, можно определить иерархию классов DisplayManager:
class DisplayManager { ... };
class DisplayUNIX : public DisplayManager { ... };
class DisplayPC : public DisplayManager { ... };
Наш класс ZooAnimal не является разновидностью класса DisplayManager, но содержит экземпляр последнего посредством композиции, а не наследования. Возникает вопрос: использовать композицию по значению или по ссылке?
Композиция по значению не может представить объект DisplayManager, с помощью которого можно будет адресовать либо объект DisplayUNIX, либо объект DisplayPC. Только ссылка или указатель на объект DisplayManager позволят нам полиморфно манипулировать его подтипами. Иначе говоря, объектно-ориентированное программирование поддерживается только композицией по ссылке (подробнее см. [LIPPMAN96a].)
Теперь нужно решить, должен ли член класса ZooAnimal быть ссылкой или указателем на DisplayManager:
* член может быть объявлен ссылкой лишь в том случае, если при создании объекта ZooAnimal имеется реальный объект DisplayManager, который не будет изменяться по ходу выполнения программы;
* если применяется стратегия отложенного выделения памяти, когда память для объекта DisplayManager выделяется только при попытке вывести объект на дисплей, то объект следует представить указателем, инициализировав его значением 0;
* если мы хотим переключать режим вывода во время выполнения, то тоже должны представить объект указателем, который инициализирован нулем. Под переключением мы понимаем предоставление пользователю возможности выбрать один из подтипов DisplayManager в начале или в середине работы программы.
Конечно, маловероятно, что для каждого подобъекта ZooAnimal в нашем приложении будет нужен собственный подтип DisplayManager для отображения. Скорее всего мы ограничимся статическим членом в классе ZooAnimal, указывающим на объект DisplayManager.
Упражнение 18.6
Объясните, в каких случаях имеет место наследование типа, а в каких – наследование реализации:
(a) Queue : List // очередь : список
(b) EncryptedString : String // зашифрованная строка : строка
(c) Gif : FileFormat
(d) Circle : Point // окружность : точка
(e) Dqueue : Queue, List
(f) DrawableGeom : Geom, Canvas // рисуемая фигура : фигура, холст
Упражнение 18.7
Замените член IntArray в реализации PeekbackStack (см. раздел 18.3.1) на класс deque из стандартной библиотеки. Напишите небольшую программу для тестирования.
Упражнение 18.8
Сравните композицию по ссылке с композицией по значению, приведите примеры их использования.
|
| Категория: С++ | Добавил: r2d2 (29.09.2011)
|
| Просмотров: 1300
| Рейтинг: 0.0/0 |
Добавлять комментарии могут только зарегистрированные пользователи. [ Регистрация | Вход ] |
|
| Born in Ussr |
|
|
| Залогиниться |
|
|
|
| Турниры |
|
|
|
