Техника наследования

Закрепленные объявления

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

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

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

Примеры из практики

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

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

Эта форма закрепленного объявления помогает решить оставшиеся проблемы. Исправим объявление conjugate, получив правильный тип результата функции класса POINT:

conjugate: like Current is
                  ... Все остальное - в точности, как раньше ...

Теперь в каждом порожденном классе тип результата conjugate автоматически определяется заново. Так, в классе PARTICLE он меняется на класс PARTICLE.

В классе LINKABLE, найдя объявления

right: LINKABLE [G]
put_right (other: LINKABLE [G]) is...

замените LINKABLE [G] на like Current. Компонент left класса BI_LINKABLE объявите аналогично.

Эта схема применима ко многим процедурам set_attribute. В классе DEVICE имеем:

class DEVICE feature
         alternate: like Current
         set_alternate (a: like Current) is
                           -- Пусть a - альтернативное устройство.
                  do
                           alternate := a
                  end
         ... Прочие компоненты ...
end

Еще раз о базовых классах

С введением закрепленных типов нуждается в расширении понятие базового класса типа.

Сначала классы и типы были для нас едины, и это их свойство - отправной пункт ОО-метода, - по существу, сохраняется, хотя нам пришлось немного расширить систему типов, добавляя в классы родовые параметры. Каждый тип основан на классе и для типа определено понятие базового класса. Для типов, порожденных универсальным классом с заданными фактическими родовыми параметрами, базовым классом является универсальный класс, в котором удалены фактические параметры. Так, например, для LIST [INTEGER] базовым классом является LIST. На классах основаны и развернутые типы; и для них аналогично: для expanded SOME_CLASS [...] базовый класс - SOME_CLASS.

Закрепление типов - это еще одно расширение системы типов, которое, подобно двум предыдущим, сохраняет свойство выводимости каждого типа непосредственно из класса. Базовым для like anchor является базовый класс типа сущности anchor в текущем классе. Если anchor есть Current, базовым будет класс, в котором это объявление содержится.

Правила о закрепленных типах

Теоретически ничто не мешает нам записать like anchor для самого элемента anchor как сущности закрепленного типа. Достаточно ввести правило, которое запрещало бы циклы в декларативных цепочках.

Пусть T - тип anchor (текущий класс, если anchor есть Current ). Тогда тип like anchor совместим как с самим собой, так и с T.

Обратное определение не симметрично: единственный тип, совместимый с like anchor, - это он сам. В частности, с ним не совместим тип T. Если бы следующий код был верен:

anchor, other: T; x: like anchor
...
create other
x := other -- предупреждение: ошибочное присваивание

то в порожденном классе, где anchor меняет свой тип на U, совместимый с T, но основанный на его потомке, сущности x был бы присвоен объект типа T, а не объект типа U или U -совместимого типа, что некорректно.

Будем говорить, что x опорно-эквивалентен y, если x есть y или имеет тип like z, где z по рекурсии опорно-эквивалентен y. Присваивания: x := anchor, anchor := x, как и присваивания опорно-эквивалентных (anchor-equivalent) элементов, конечно же, допустимы.

При закреплении формального параметра или результата, как в случае

r (other: like Current)

фактический параметр вызова, например, b в a.r(b), должен быть опорно-эквивалентен a.

Когда не используются закрепленные объявления

Не всякое объявление вида x: A в классе A следует менять на x: like Current и не в каждой паре компонентов одного типа следует один из них делать опорным, а другой - закрепленным.

Закрепленное объявление - это своего рода обязательство изменения типа закрепленной сущности при смене типа опорного элемента. Как мы видели, оно не имеет обратной силы: объявив тип сущности как like anchor, вы теряете право на переопределение его в будущем (коль скоро новый тип должен быть совместим с исходным, а с закрепленным типом совместим только он сам). Пока не введено закрепление, остается свобода: если x типа T, то потомок может переопределить тип, введя более походящий тип U.

Достоинства и недостатки закрепления сущностей очевидны. Закрепление гарантирует, что вам не придется выполнять повторные объявления вслед за изменением типа опорного элемента, но оно раз и навсегда привязывает вас к типу опорного элемента. Это типичный случай "свободы выбора". (В каком-то смысле Фауст объявил себя like Мефистофель.)

Как пример нежелательного закрепления рассмотрим компонент first_child для деревьев, описывающий первого сына данного узла дерева. (При построении дерева он аналогичен компоненту first_element для списков, типом которого изначально является CELL [G] или LINKABLE [G].) Для деревьев требуется повторное объявление. Может показаться, что уместным использовать закрепленное объявление:

first_child: like Current

Но на практике это накладывает слишком много ограничений. Класс дерева может иметь потомков, представляющих разные виды деревьев (их узлов): UNARY_TREE (узлы с одним сыном), BINARY_TREE (узлы с двумя сыновьями) и BOUNDED_ARITY_TREE (узлы с ограниченным числом сыновей). При закреплении first_child все сыновья каждого узла должны иметь один и тот же отцовский тип.

Это может быть нежелательным при построении более гибких структур, например бинарного узла с унарным потомком. Для этого компонент нужно описать без закрепления:

first_child: TREE [G]

Это решение не связано с какими-то ограничениями, и для создания деревьев с узлами одного типа вы, оставив класс TREE без изменений, можете породить от него HOMOGENEOUS_TREE, где переопределить first_child как

first_child: like Current

что гарантирует неизменность типов всех узлов дерева.

Статический механизм

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

Закрепленное объявление можно считать синтаксическим приемом, позволяющим переложить переопределения на компилятор. Кроме того, оно является важнейшим инструментом достижения компромисса между повторным использованием и контролем типов.