Набрали: Валентин Буров, Илья Тюрин

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

Содержание

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

1 ... 11 12 13 14 15 16 17 18 19

Динамическое связывание методов

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

Ранее мы рассмотрели это понятие на примере C++ и Oberon-2 и увидели, как работают соответствующие динамические связанные методы, в Oberon-2 это: процедуры, привязанные к типу; в C++ - виртуальные функции-члены. Безусловно, речь идет об одних и тех же понятиях.

У нас есть интерфейс, а именно:

<возвр. тип> <имя> <аргументы>

этот интерфейс неизменен, и он должен быть прописан в классе наиболее высокого уровня (необязательно в корневом). Этот интерфейс является частью класса. При этом соответствующее имя объявлено с ключевым словом virtual в C++, либо, по синтаксису отличаясь, как привязанная к типу процедура в Oberon. И далее, все наследующие классы обязаны сохранять интерфейс неизменным. Таким образом, у нас возникает несколько тел функции с одним интерфейсом. При этом какое тело будет вызвано зависит исключительно от динамического типа соответствующей переменной.

То есть в Oberon-2 тоже есть соответствующий аргумент, когда мы пишем процедуру

PROCEDURE (P: T) имя (...);

В C++ роль аргумента P играет неявный указатель на объект this. И, исходя из динамического типа объекта, выбирается нужная функция.

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

class Shape {

int x,y;

...

virtual void Draw(bool erase); //она виртуальна, ее

//параметр говорит, что

//нужно сделать – стереть

//или нарисовать

void Move (int dx, int dy);

{ Draw (true);

x +=dx; y+=dy;

Draw (false);

}

}

Заметим, что метод Move может быть и невиртуальным, поскольку вся его специфика заключена в специфике метода Draw, который уже виртуальный. Смысла делать его виртуальным – никакого, однако, он сам вызывает виртуальный метод. Если мы будем вызывать:

Shape *p;

p->Move(1,1);

совершенно понятно, что будет вызвана конкретная функция Move для класса Shape, но она уже, в свою очередь, вызовет виртуальный метод Draw, конкретизация которого зависит от динамического типа p, то есть Draw будет вызван нужный, причем сделано это будет без участия программиста, в том плане, что не нужно никого никуда присваивать, писать сложные конструкции и т.д. И вообще, ООП не может быть без виртуальных методов или их аналогов. Более того, что в чистых объектно-ориентированных языках (заметим, что C++ сюда не относится), например, Java и Smalltalk нет невиртуальных методов, любой вызов метода зависит от динамического типа объекта. Понятно, что в C++ невиртуальные методы сделаны исключительно из совместимости с С. Хотелось, чтобы текст, написанный на С, по-крайне мере по распределению памяти совпадал с тем, что будет понято компилятором C++. Например:

class Complex {

...

};

в этом классе (или структуре с точки зрения C) нет ничего динамического. Поэтому Страуструп ввел два вида методов – виртуальные и невиртуальные.

Посмотрим, какие у нас возникают накладные расходы, связанные с реализацией виртуальных методов. Реализация очень простая и снимает всю мистику с этого вопроса.

Рассмотрим вырожденный пример:

class X {

int a;

void g();

virtual void f( );

virtual void h( );

}

class Y : public X {

void g( );

void f( );

void h( );

int b;

}

То, что у нас функции g ( ) в обоих классах имеют одинаковый интерфейс значения не имеет, так как компилятор определеяет вызов соответствующего метода статически, если указатель описан класса X, то будет вызвана g( ) из класса X, причем динамический тип объекта не важен (он может быть и Y). В то же время для f и h это уже будет не так. Заметим, что в описании Y писать virtual для f и h уже необязательно – это свойство установлено выше в X и снять его уже никак нельзя, интерфейсы всех виртуальных одноименных функций обязаны быть одинаковыми, иначе функция будет перегружена (о чем, возможно, скажет компилятор, однако ошибки в этом нет).

Вспомним пример из предыдущей лекции:

X *px = new X;

Y *py = new Y;

px->f( ); //X::f( )

px->g( ); //X::g( )

py->f( ); //Y::f( )

py->g( ); //Y::g( )

px=py;

px->f( ); //Y::f( )

px->g( ); //X::g( )

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

Как же это все реализуется? Для каждого класса существует табличка, которая называется Таблицей Виртуальных Методов. Она существует для каждого класса, у которого есть виртуальные методы (они могут быть унаследованы или созданы). Как только появляется в классе виртуальный метод, то компилятор генерирует ТВМ. Она состоит из указателей на конкретные виртуальные методы (она инициализируется в момент загрузки программы). Для X ТВМ будет выглядеть следующим образом:

f	X::f
h	X::h

Для Y:

f	Y::f
h	Y::h

Представим, что у нас есть третий класс Z, в нем мы одну функцию переопределим, а одну добавим:

class Z public Y {

void f ( ); int c;

virtual i( );

};

Заметим, что функции h( ) в Z нет, она будет унаследована от Y. Для Z ТВМ:

f	Z::f
h	Y::h
i	Z::i

ТВМ создаются таким образом, что порядок всех определенных функций у класса одной цепочки наследования – одинаков. То есть смещения виртуальных функций в ТВМ для всех таких классов – одинаковы: f( ) имеет смещение 0, h( ) - +1, если появляются новые, то они добавляются далее. И любой класс-наследник получит эту таблицу именно с таким порядком.

Каков же вид объекта? Его структура становится следующей (учитывая то, что следует указывать для класса его ТВМ):

X:

Ссылка на ТВМ для X

Ссылка на ТВМ для Y

Ссылка на ТВМ для Z

И конкретная ссылка на ТВМ для каждого экземпляра объекта определяется динамически. Также ссылка на ТВМ всегда имеет фиксированное значение (в данном случае нулевое) для любых классов, унаследованных от X. И, собственно, этим свойством и пользуется комппилятор, когда генерирует код для вызова виртуальных функций.

PX = new X;

ссылка на ТВМ X

Поскольку компилятор знает, что функция f( ) имеет нулевое смещение, то будет вызвана та функция, которая имеет нулевое смещение. Понятно, что конкретная функция будет зависеть от того, каков динамический тип переменной.

Если, например, было присваивание:

px=py,

то для px картина теперь выглядит так::

ссылка на ТВМ Y

Нижнюю часть (переменную b) мы, вообще говоря, не видим, но это и неважно. Важно то, что теперь по нулевому смещению стоит ссылка на ТВМ Y, а значит все виртуальные функции исполняются так, как они прописаны в ТВМ Y.

Рассмотрим ситуацию при

px=pz;

px->h;

ссылка на ТВМ Z

При px->h будет вызвана функция Y::h(), так как именно она прописана в ТВМ Z (она наследуется Z от Y).

Указатель на ТВМ и есть информация о динамическом типе. Заметим, что ТВМ может содержать и бОльшую информацию, например, название типа. Но главное все-таки и обязательное – это таблица функций.

Blog

Набрали: Валентин Буров, Илья Тюрин

Содержание

Динамическое связывание методов