Наследование. Шаблоны классов

Виртуальные методы

Работа с объектами чаще всего производится через указатели. Указателю на базовый класс можно присвоить значение адреса объекта любого производного класса, например:

monster *p;	// Описывается указатель на базовый класс
p = new daemon;	/* Указатель ссылается на объект производного класса */

Вызов методов объекта происходит в соответствии с типом указателя, а не фактическим типом объекта, на который он ссылается, поэтому при выполнении оператора, например,

p -> draw(1, 1, 1, 1);

будет вызван метод класса monster, а не класса daemon, поскольку ссылки на методы разрешаются во время компоновки программы. Этот процесс называется ранним связыванием. Чтобы вызвать метод класса daemon, можно использовать явное преобразование типа указателя:

((daemon * p)) -> draw(1, 1, 1, 1);

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

В качестве примера можно привести функцию, параметром которой является указатель на объект базового класса. На его место во время выполнения программы может быть передан указатель любого производного класса. Другой пример - связный список указателей на различные объекты иерархии, с которым требуется работать единообразно.

В С++ реализован механизм позднего связывания, когда разрешение ссылок на функцию происходит на этапе выполнения программы в зависимости от конкретного типа объекта, вызвавшего функцию. Этот механизм реализован с помощью виртуальных методов.

Для определения виртуального метода используется спецификатор virtual:

virtual void draw(int x, int y, int scale, int position);

Рассмотрим правила использования виртуальных методов.

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

Чисто виртуальный метод содержит признак = 0 вместо тела, например:

virtual void f(int) = 0;

Чисто виртуальный метод должен переопределяться в производном классе (возможно, опять как чисто виртуальный).

Если определить метод draw в классе monster как виртуальный, решение о том, метод какого класса вызвать, будет приниматься в зависимости от типа объекта, на который ссылается указатель:

monster *r, *p;
r = new monster;	// Создается объект класса monster
p = new daemon;			// Создается объект класса daemon
r -> draw(1,1,1,1);		// Вызывается метод monster::draw
p -> draw(1,1,1,1);		// Вызывается метод daemon::draw
p -> monster::draw(1,1,1,1);	//	Обход механизма виртуальных методов

Если объект класса daemon будет вызывать метод draw не непосредственно, а косвенно (то есть из другого метода, который может быть определен только в классе monster ), будет вызван метод draw класса daemon.

Итак, виртуальным называется метод, ссылка на который разрешается на этапе выполнения программы (перевод красивого английского слова virtual - всего-навсего "фактический", то есть ссылка разрешается по факту вызова).

Рассмотрим механизм позднего связывания.

Для каждого класса (не объекта!), содержащего хотя бы один виртуальный метод, компилятор создает таблицу виртуальных методов ( vtbl ), в которой для каждого виртуального метода записан его адрес в памяти. Адреса методов содержатся в таблице в порядке их описания в классах. Адрес любого виртуального метода имеет в vtbl одно и то же смещение для каждого класса в пределах иерархии.

Каждый объект содержит скрытое дополнительное поле ссылки на vtbl, называемое vptr. Оно заполняется конструктором при создании объекта (для этого компилятор добавляет в начало тела конструктора соответствующие инструкции).

На этапе компиляции ссылки на виртуальные методы заменяются на обращения к vtbl через vptr объекта, а на этапе выполнения в момент обращения к методу его адрес выбирается из таблицы. Таким образом, вызов виртуального метода, в отличие от обычных методов и функций, выполняется через дополнительный этап получения адреса метода из таблицы. Это несколько замедляет выполнение программы, поэтому без необходимости делать методы виртуальными смысла не имеет.

Рекомендуется делать виртуальными деструкторы для того, чтобы гарантировать правильное освобождение памяти из-под динамического объекта, поскольку в любой момент времени будет выбран деструктор, соответствующий фактическому типу объекта.

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

Для пояснения последнего тезиса представим себе, что вызов метода draw осуществляется из метода перемещения объекта. Если текст метода перемещения не зависит от типа перемещаемого объекта (поскольку принцип перемещения всех объектов одинаков, а для отрисовки вызывается конкретный метод), переопределять этот метод в производных классах нет необходимости, и он может быть описан как невиртуальный. Если метод draw виртуальный, метод перемещения сможет без перекомпиляции работать с объектами любых производных классов - даже тех, о которых при его написании ничего известно не было.

Виртуальный механизм работает только при использовании указателей или ссылок на объекты. Объект, определенный через указатель или ссылку и содержащий виртуальные методы, называется полиморфным. В данном случае полиморфизм состоит в том, что с помощью одного и того же обращения к методу выполняются различные действия в зависимости от типа, на который ссылается указатель в каждый момент времени.

Абстрактные классы

Класс, содержащий хотя бы один чисто виртуальный метод, называется абстрактным. Абстрактные классы предназначены для представления общих понятий, которые предполагается конкретизировать в производных классах. Абстрактный класс может использоваться только в качестве базового для других классов - объекты абстрактного класса создавать нельзя, поскольку прямой или косвенный вызов чисто виртуального метода приводит к ошибке при выполнении.

При определении абстрактного класса необходимо иметь в виду следующее:

• Абстрактный класс нельзя использовать при явном приведении типов, для описания типа параметра и типа возвращаемого функцией значения;
• Допускается объявлять указатели и ссылки на абстрактный класс, если при инициализации не требуется создавать временный объект.
• Если класс, производный от абстрактного, не определяет все чисто виртуальные функции, он также является абстрактным.

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

Множественное наследование

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

class monster
{
	public: int get_health(); 
	... 
};
class hero
{
	public: int get_health(); 
	... 
};
class being: public monster, public hero{ ... };
int main(){
	being A;
	cout << A.monster::get_health();
	cout << A.hero::get_health();}

Использование конструкции A.get_health() приведет к ошибке, поскольку компилятор не в состоянии разобраться, метод какого из базовых классов требуется вызвать.

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

class monster{ ... };
class daemon: virtual public monster{ ... };
class lady: virtual public monster{ ... };
class god: public daemon, public lady{ ... };

Класс god содержит только один экземпляр полей класса monster.

Альтернатива наследованию

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

Альтернативой наследованию при проектировании классов является вложение, когда один класс включает в себя поля, являющиеся классами или указателями на них. Например, если есть класс "двигатель", а требуется описать класс "самолет", логично сделать двигатель полем этого класса, а не его предком.

Вид вложения, когда в классе описано поле объектного типа, называют композицией. Если в классе описан указатель на объект другого класса, это обычно называют агрегацией. При композиции время жизни всех объектов (и объемлющего, и его полей) одинаково. Агрегация представляет собой более слабую связь между объектами, потому что объекты, на которые ссылаются поля-указатели, могут появляться и исчезать в течение жизни содержащего их объекта, кроме того, один и тот же указатель может ссылаться на объекты разных классов в пределах одной иерархии. Поле-указатель может также ссылаться не на один объект, а на неопределенное количество объектов, например быть указателем на начало линейного списка.

Отличия структур и объединений от классов

Структуры ( struct ) и объединения ( union ) представляют собой частные случаи классов. Структуры отличаются от классов тем, что доступ к элементам, а также базовый класс при наследовании по умолчанию считаются public. Структуры предпочтительнее использовать для объектов, все элементы которых доступны.

Доступ в объединениях также устанавливается public, кроме того, в них вообще нельзя использовать спецификаторы доступа (уточнение: зависит от реализации). Объединение не может участвовать в иерархии классов. Элементами объединения не могут быть объекты, содержащие конструкторы и деструкторы. Объединение может иметь конструктор и другие методы, только не статические. (Уточнение: статическими не могут быть только переменные union (свойства).) В анонимном объединении методы описывать нельзя.