Правильное использование попытки присваивания
Необходимость попытки присваивания обусловлена, как правило, тем, что на статически объявленный тип сущности положиться нельзя, а опознать тип фактически адресуемого объекта необходимо "на лету". Например, при работе с полиморфными структурами данных и получении объектов из третьих рук.
Заметьте, как тщательно был спроектирован механизм, дающий разработчикам шанс забыть об устаревшем стиле разбора вариантов (case-by-case). Если вы действительно хотите перехитрить динамическое связывание и отдельно проверять каждый вариант типа, вы можете это сделать, хотя вам и придется немало потрудиться. Так, вместо обычного f.display, использующего ОО-механизмы полиморфизма и динамического связывания, можно, - но не рекомендуется, - писать:
display (f: FIGURE) is
-- Отобразить f, используя алгоритм,
-- адаптируемый к истинной природе объекта.
local
r: RECTANGLE; t: TRIANGLE; p: POLYGON; s: SQUARE
sg: SEGMENT; e: ELLIPSE; c: CIRCLE;?
do
r ?= f; if r /= Void then "Использовать алгоритм вывода прямоугольника" end
t ?= f; if t /= Void then "Использовать алгоритм вывода треугольника" end
c ?= f; if c /= Void then "Использовать алгоритм вывода окружности" end
... и т.д. ...
end
На практике такая схема даже хуже, чем кажется, так как структура наследования имеет несколько уровней, а значит, усложнения управляющих конструкций не избежать.
Из-за трудностей написания таких закрученных конструкций попытки присваивания новичкам вряд ли придет в голову использовать их вместо привычной ОО-схемы. Однако и опытные специалисты должны помнить о возможности неправильного использования конструкции.
Типизация и повторное объявление
Повторное объявление компонентов не требует сохранения сигнатуры. Пока оно виделось нам как замена одного алгоритма другим или - для отложенного компонента - запись алгоритма, соответствующего ранее заданной спецификации.
Но, воплощая идею о том, что класс способен предложить более специализированную версию элемента, описанного его предком, мы вынуждены иногда изменять типы данных. Приведем два характерных примера.
Устройства и принтеры
Вот простой пример переопределения типа. Рассмотрим понятие устройства, включив предположение о том, что для любого устройства есть альтернатива, так что устройство можно заменить, если оно по каким-либо причинам недоступно:
class DEVICE feature
alternate: DEVICE
set_alternate (a: DEVICE) is
-- Пусть a - альтернативное устройство.
do
alternate := a
end
... Прочие компоненты ...
end
Принтер является устройством, так что использование наследования оправдано. Но альтернативой принтера может быть только принтер, но не дисковод для компакт-дисков или сетевая карта, - поэтому мы должны переопределить тип:
Рис. 16.6. Устройства и принтеры
class PRINTER inherit
DEVICE
redefine alternate, set_alternate
feature
alternate: PRINTER
set_alternate (a: PRINTER) is
-- Пусть a - альтернативное устройство.
... Тело как у класса DEVICE ...
... Прочие компоненты ...
end
В этом и проявляется специализирующая природа наследования.
Одно- и двусвязные элементы
В следующем примере мы обратимся к базовым структурам данных. Рассмотрим библиотечный класс LINKABLE, описывающий односвязные элементы, используемые в LINKED_LIST - одной из реализаций списков. Вот частичное описание класса:
indexing
description: "Односвязные элементы списка"
class LINKABLE [G] feature
item: G
right: LINKABLE [G]
put_right (other: LINKABLE [G]) is
-- Поместить other справа от текущего элемента.
do right := other end
... Прочие компоненты ...
end
Рис. 16.7. Односвязный элемент списка
Ряд приложений требуют двунаправленных списков. Класс TWO_WAY_LIST - наследник LINKED_LIST должен быть также наследником класса BI_LINKABLE, являющегося наследником класса LINKABLE.
Рис. 16.8. Параллельные иерархии
Двусвязный элемент списка имеет еще одно поле:
Рис. 16.9. Двусвязный элемент списка
В состав двунаправленных списков должны входить лишь двусвязные элементы (хотя последние, в силу полиморфизма, вполне можно внедрять и в однонаправленные структуры). Переопределив right и put_right, мы гарантируем однородность двусвязных списков.
indexing
description: "Элементы двусвязного списка"
class BI_LINKABLE [G] inherit
LINKABLE [G]
redefine right, put_right end
feature
left, right: BI_LINKABLE [G]
put_right (other: BI_LINKABLE [G]) is
-- Поместить other справа от текущего элемента.
do
right := other
if other /= Void then other.put_left (Current) end
end
put_left (other: BI_LINKABLE [G]) is
-- Поместить other слева от текущего элемента.
... Упражнение для читателя ...
... Прочие компоненты ...
invariant
right = Void or else right.left = Current
left = Void or else left.right = Current