Движения произвольных фигур

Чтобы понять необходимость в отложенных процедурах и классах, снова рассмотрим иерархию фигур FIGURE.

Рис. 14.8. Снова иерархия FIGURE

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

transform (f: FIGURE) is

-- Применить специфическое преобразование к f.

do

f.rotate (...)

f.translate (...)

end

с соответствующими значениями опущенных аргументов. Тогда все следующие вызовы корректны:

transform (r) -- для r: RECTANGLE

transform (c) -- для c: CIRCLE

transform (figarray.item (i)) -- для массива фигур: ARRAY [POLYGON]

Иными словами, требуется применить преобразования rotate и translate к фигуре f и предоставить механизму динамического связывания выбор подходящей версии (различной для классов RECTANGLE и CIRCLE), зависящей от текущего вида фигуры f, который выяснится во время выполнения.

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

Но переопределять-то нечего! Класс FIGURE - это очень общее понятие, покрывающее все виды двумерных фигур. Ясно, что невозможно написать версию процедур rotate и translate, подходящую для всех фигур "вообще", не уточнив информацию об их виде.

Таким образом, мы имеем ситуацию, в которой процедура transform будет выполняться корректно, благодаря динамическому связыванию, но статически она незаконна, поскольку rotate и translate не являются компонентами класса FIGURE. Проверка типов выявит в вызовах f.rotate и f.translate ошибки.

Можно, конечно, ввести на уровне класса FIGURE процедуру rotate, которая ничего не будет делать. Но это опасный путь, компоненты rotate (center, angle) имеют интуитивно хорошо понятную семантику и "ничего не делать" не является их разумной реализацией.