Несогласованность типов

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

Рис. 16.10. Добавление элемента

put_right (v: G) is

-- Вставить элемент v справа от курсора.

-- Не передвигать курсор.

require

not after

local

new: LINKABLE [T]

do

create new.make (v)

put_linkable_right (new)

...

ensure

... См. приложение A...

end

Для вставки нового элемента, имеющего значение v, необходимо предварительно создать элемент типа LINKABLE [G]. Вставка производится закрытой процедурой put_linkable_right, принимающей LINKABLE как параметр (и связывающей его с текущим элементом, используя процедуру put_right класса LINKABLE). Эта процедура осуществляет все нужные манипуляции со ссылками.

У потомков LINKED_LIST, таких как TWO_WAY_LIST или LINKED_TREE, процедура put_right тоже должна быть применимой. Но у них она работать не будет! Хотя алгоритм ее остается корректным, сущность new для них должна иметь другой тип - BI_LINKABLE или LINKED_TREE. Поэтому в каждом потомке нужно переопределять и переписывать целую процедуру, и это притом, что ее тело будет идентично оригиналу, за исключением переопределения new! Для подхода, претендующего на решение проблемы повторного использования, это серьезный порок.