Бертран Мейер - Основы объектно-ориентированного программирования

... См. приложение 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 ! Для подхода, претендующего на решение проблемы повторного использования, это серьезный порок.

Было бы ошибочно полагать, что проблема неоправданного переопределения возникает лишь там, где структура ориентирована на реализацию, как в LINKED_LIST . В любой схеме вида

some_attribute: SOME_TYPE

set_attribute (a: SOME_TYPE) is do ... end

переопределение some_attribute подразумевает соответствующее переопределение set_attribute . В случае с put_right из BI_LINKABLE (не путайте с подпрограммой из LINKED_LIST ) повторное определение необходимо, поскольку фактически меняется алгоритм. Но во многих широко распространенных случаях (к примеру, в set_alternate ) новый алгоритм идентичен исходному.

Вот еще один пример, показывающий глубину проблемы (не ограниченной лишь процедурами set_xxx , которые сами появились в силу принципа Скрытия информации). Добавим в класс POINT функцию, которая возвращает точку, сопряженную с данной, - ее зеркальное отражение относительно горизонтальной оси:

Рис. 16.11. Исходная и сопряженная точка

conjugate: POINT is

-- Точка, сопряженная с текущей

do

Result := clone (Current) -- Получить копию текущей точки

Result.move (0, -2*y) -- Перенести результат по вертикали

end

Рассмотрим теперь некий класс, порожденный от POINT , например PARTICLE . К атрибутам частиц, помимо координат, относятся, вероятно, масса и скорость. По идее, функция conjugate применима и к PARTICLE и выдает в результате ту же частицу с противоположным значением координаты y . Но если оставить все как есть, функция работать не будет из-за несоблюдения правила совместимости типов:

p1, p2: PARTICLE; create p1.make (...); ...

p2 := p1.conjugate

Правая часть подчеркнутого оператора имеет тип POINT , левая часть - тип PARTICLE . Правило совместимости типов этого не допускает. Поэтому мы должны переписать conjugate для PARTICLE с единственной целью - обеспечить соблюдение правила.

Изучив класс LINKED_LIST в тексте приложения A, вы поймете, что проблема еще масштабнее. В теле класса содержится множество объявлений со ссылкой на тип LINKABLE [G] , а с переходом к двунаправленным спискам почти все они потребуют повторного определения. Так, вариант представления списка включает четыре ссылки на отдельные элементы:

first_element, previous, active, next: LINKABLE [G]

В классе TWO_WAY_LIST каждая из этих сущностей должна быть объявлена заново. Аналогичная процедура ждет и другие порожденные классы. Многие функции, такие как put_right , имеют "односвязные" аргументы и нуждаются в повторном определении. В итоге реализация TWO_WAY_LIST будет во многом дублировать оригинал.

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

Заметим: наши примеры действительно требуют переопределения типа, но ничего более. Все сводится только к этому. Из этого следует решение проблемы - необходимо создать механизм не абсолютного, а относительногообъявления типа сущности.

Назовем такое объявление закрепленным (anchored). Пусть закрепленное объявление типа имеет вид

like anchor

где anchor , именуемый опорным (anchor) элементом объявления, - это либо запрос (атрибут или функция) текущего класса, либо предопределенное выражение Current . Описание my_entity: like anchorв классе A , где anchor - запрос, означает выбор для сущности типа, аналогичного anchor , с оговоркой, что любое переопределение anchor вызовет неявное переопределение my_entity .

Если anchor имеет тип T , то в силу закрепленного объявления my_entity в классе A будет трактоваться так, будто тоже имеет тип T . Рассматривая лишь класс A , вы не найдете различий между объявлениями:

my_entity: like anchor

my_entity: T

Различия проявятся только в потомках A . Будучи описана подобной ( like) anchor , сущность my_entity автоматически будет следовать всем переопределениям типа anchor , освобождая от них автора класса.

Обнаружив, что класс содержит ряд сущностей, чьи потомки должны переопределяться одинаково, вы можете избавить себя от всех переопределений, кроме одного, объявив все элементы "подобными" ( like) первому и определяя заново лишь его. Остальное будет сделано автоматически.

Вернемся к LINKED_LIST . Выберем first_element в качестве опорного для других сущностей типа LINKABLE [G] :

first_element: LINKABLE [G]

previous, active, next: like first_element

Локальная сущность new процедуры put_right класса LINKED_LIST тоже должна иметь тип like first_element, и это - единственное изменение в процедуре. Теперь достаточно переопределить first_element как BI_LINKABLE в классе TWO_WAY_LIST , как LINKED_TREE в LINKED_TREE и т.д. Сущности, описанные как like, не нужно указывать в предложении redefine. Не требуется и повторное определение put_right .

Итак, закрепленные определения есть весьма важное средство сохранения возможности повторного использования при статической типизации.

В качестве опорного элемента можно использовать Current , обозначающий текущий экземпляр класса (о текущем экземпляре см. лекцию 7). Сущность, описанная в классе A как like Current, будет считаться в нем имеющей тип A , а в любом B , порожденном от A , - имеющей тип B .