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

Было бы ошибочно полагать, что проблема неоправданного переопределения возникает лишь там, где структура ориентирована на реализацию, как в 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 , освобождая от них автора класса.