Основы объектно-ориентированного программирования
Использование правильного варианта
Операции, определенные для всех вариантов многоугольников, могут реализовываться по-разному. Например, perimeter (периметр) имеет разные версии для общих многоугольников и для прямоугольников, назовем эти версии perimeterPOL и perimeterRECT. У класса SQUARE также будет свой вариант (умноженная на 4 длина стороны). При этом естественно возникает важный вопрос: что случится, если программа, имеющая разные версии, будет применена к полиморфной сущности?
Во фрагменте
create p.make (...); x := p.perimeter
ясно, что будет использована версия perimeterPOL. Точно так же во фрагменте
create r.make (...); x := r.perimeter
будет использована версия perimeterRECT. Но что, если полиморфная сущность p статически объявлена как многоугольник, а динамически ссылается на прямоугольник? Предположим, что нужно выполнить фрагмент:
create r.make (...) p := r x := p.perimeter
Правило динамического связывания утверждает, что версию применяемой операции определяет динамическая форма объекта. В данном случае это будет perimeterRECT.
Конечно, более интересный случай возникает, когда из текста программы нельзя заключить, какой динамический тип будет иметь p во время выполнения. Например, что будет во фрагменте
-- Вычислить периметр фигуры выбранной пользователем p: POLYGON ... if chosen_icon = rectangle_icon then create {RECTANGLE} p.make (...) elseif chosen_icon = triangle_icon then create {TRIANGLE} p.make (...) elseif ... end ... x := p.perimeter
или после условного полиморфного присваивания if ... then p := r elseif ... then p := t ..., ; или если p является элементом полиморфного массива многоугольников, или если p является формальным аргументом с объявленным типом POLYGON некоторой процедуры, которой вызвавшая ее процедура передала фактический аргумент согласованного типа?
Тогда в зависимости от хода вычисления динамическим типом p будет RECTANGLE, или TRIANGLE, или т.п. У нас нет никакого способа узнать, какой из этих случаев будет иметь место. Но, благодаря динамическому связыванию, этого и не нужно знать: что бы ни случилось с p, при вызове будет выполнен правильный вариант компонента perimeter.
Эта способность операций автоматически приспосабливаться к тем объектам, к которым они применяются, является одной из главных особенностей ОО-систем, непосредственно относящейся к обсуждаемым в начале книги вопросам качества ПО. Ее последствия будут подробней рассмотрены далее в этой лекции.
Динамическое связывание позволяет завершить начатое выше обсуждение аспектов, связанных с потерей информации при полиморфизме. Сейчас стало понятно, почему не страшно потерять информацию об объекте: после присваивания p := q или вызова some_routine (q), в котором p являлся формальным аргументом, теряется специфическая информация о типе q, но если применяется операция p.polygon_feature, для которой polygon_feature имеет специальную версию, применимую к q, то будет выполняться именно эта версия.
| Вполне допустимо посылать ваших любимцев в отдел отсутствующих хозяев, который обслуживает все виды, если наверняка известно, что, когда придет время еды, ваш кот получит кошачью еду, а пес - собачью. |
