Понятие опорного элемента

Серьезное затруднение

Изучив класс 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.

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

Дата добавления: 2014-01-07