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

Что делать с отложенными классами?

Присутствие отложенных элементов в системе вызывает вопрос: 'что случится, если компонент rotate применить к объекту типа FIGURE?' или в общем виде - 'можно ли применить отложенный компонент к прямому экземпляру отложенного класса?' Ответ может обескуражить: такой вещи как объект типа FIGURE не существует - прямых экземпляров отложенных классов не бывает.

Правило отсутствия экземпляров отложенных классов

Тип создания в процедуре создания не может быть отложенным.

Напомним, что тип создания - это тип x, для формы create x, и U для формы create {U} x. Тип считается отложенным, если таков его базовый класс.

Поэтому вызов конструктора create f некорректен и будет отвергнут компилятором, если типом f будет один из отложенных классов: FIGURE, OPEN_FIGURE, CLOSED_FIGURE. Это правило устраняет опасность ошибочных вызовов компонентов.

Отметим однако, что даже, если тип сущности f отложенный, то допустима явная форма процедуры создания - create{RECTANGLE} f, поскольку здесь типом создания является эффективный потомок FIGURE - класс RECTANGLE. Мы уже видели, как этот прием используется в многовариантной процедуре создания для объектов класса FIGURE, которые, в зависимости от контекста, будут экземплярами эффективных классов RECTANGLE, CIRCLE и др.

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

f: FIGURE
...
f := 'Некоторое выражение эффективного типа, такого как CIRCLE или POLYGON'
...
f.rotate (some_point, some_angle)
f.display
...

Такие примеры являются комбинацией и кульминацией уникальных средств абстракции ОО-метода таких, как классы, скрытие информации, единственный выбор, наследование, полиморфизм, динамическое связывание, отложенные классы (и, как будет видно дальше, утверждения). Вы манипулируете объектами, не зная точно их типов, задавая только минимум информации, необходимой для требуемых операций. Имея надежный штамп контролера типов, удостоверяющий согласованность вызовов этих операций с их объявлениями, можно рассчитывать на большую силу - динамическое связывание, которая позволяет применять корректную версию каждой операции, не зная точно, что это за версия.

Задание семантики отложенных компонентов и классов

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

Как и другие классы, отложенный класс может иметь инвариант, а у отложенного компонента может быть предусловие, постусловие или оба эти утверждения.

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

Рис. 14.9.  Список с курсором

Этот класс является отложенным:

indexing
description: 'Линейные списки'
deferred class
LIST [G]
feature -- Access
count: INTEGER is
-- Число элементов
deferred
end
index: INTEGER is
-- Положение курсора
deferred
end
item: G is
-- Элемент в позиции курсора
deferred
end
feature - Отчет о статусе
after: BOOLEAN is
-- Курсор за последним элементом?
deferred
end
before: BOOLEAN is
-- Курсор перед первым элементом?
deferred
end
feature - Сдвиг курсора
forth is
-- Передвинуть курсор на одну позицию вперед.
require
not after