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

Компонент clone , входящий в состав класса GENERAL , тоже имеет "двойника" standard_clone , однако обе версии заморожены. Зачем понадобилось замораживать clone ? Причина кроется не в запрете задания иной семантики операции клонирования, а в необходимости сохранения совместимости семантик copy и clone , что, как побочный эффект, облегчает задачу разработчика. Общий вид объявления clone таков:

frozen clone (other:...): ... is

-- Void если other пуст; иначе вернуть новый объект, содержимое которого скопировано

из other.

do

if other /= Void then

Result := "Новый объект того же типа, что other"

Result.copy (other)

end

ensure

equal (Result, other)

end

Фраза " Новый объект того же типа, что other" есть неформальное обозначение вызова функции, которая создает и возвращает объект того же типа, что и other . ( Result равен Void , если other - "пустой" указатель.)

Несмотря на замораживание компонента clone , он будет изменяться, соответствуя любому переопределению copy , например в классах ARRAY и STRING . Это удобно (для смены семантики copy-clone достаточно переопределить copy ) и безопасно (задать иную семантику clone было бы, скорее всего, ошибкой).

Переопределять clone не нужно (да и нельзя), однако при переопределении copy понадобится переопределить и семантику равенства. Как сказано в постусловиях компонентов copy и clone , результатом копирования должны быть тождественные объекты. Сама функция equal , по сути, зафиксирована, как и clone , но она зависит от компонентов, допускающих переопределение:

frozen equal (some, other: ...): BOOLEAN is

-- Обе сущности some и other пусты или присоединены

-- к объектам, которые можно считать равными?

do

Result := ((some = Void) and (other = Void)) or else some.is_equal (other)

ensure

Result = ((some = Void) and (other = Void)) or else some.is_equal (other)

end

Вызов equal (a, b) не соответствует строгому ОО-варианту a.is_ equal (b) , но на практике выгодно отличается от него, будучи применим, даже если a или b пусто. Базовый компонент is_equal не заморожен и требует согласованного переопределения в любом классе, переопределяющем copy . Это делается для того, чтобы семантика равенств оставалась совместимой с семантикой copy-clone , а постусловия copy и clone были по-прежнему верными.

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

Замораживание компонентов не следует делать по соображениям эффективности. (Эту ошибку иногда совершают программисты, работающие на C++ или Smalltalk, которым внушили мысль, будто динамическое связывание накладно и его нужно по возможности избегать.) Хотя вызов замороженных компонентов означает отсутствие динамического связывания, это лишь побочный эффект механизма frozen, а не его конечная цель. Выше мы подробно говорили о том, что безопасное статическое связывание - это проблема оптимизации, и решает ее компилятор, а не программист. В грамотно спроектированном языке компилятор обладает всем необходимым для такой и даже более сильной оптимизации, скажем, для подстановки тела функции в точку вызова (routine inlining). Поиск возможностей оптимизации - задача машин, а не человека. Пользуйтесь frozenв редких, но важных для себя случаях, когда это действительно необходимо (для обеспечения точного соответствия семантике исходной реализации), и пусть ваш язык и ваш компилятор делают свою работу.

Расширяя базовое понятие класса, мы представляли наследование и универсальность (genericity) как своего рода "партнеров". Объединить их нам позволило знакомство с полиморфными структурами данных: в контейнер - объект, описанный сущностью типа SOME_CONTAINER_TYPE [T] с родовым параметром T - можно помещать объекты не только самого типа T , но и любого потомка T . Однако есть и другая интересная комбинация партнерства, в которой наследование используется для задания ограничения на возможный тип фактического родового параметра класса.

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

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

indexing

description: "Векторы со сложением"

class

VECTOR [G]

feature -- Доступ

count: INTEGER

-- Количество элементов

item, infix "@" (i: INTEGER): G is

-- Элемент вектора с индексом i (нумерация с 1)

require ... do

...

end

feature -- Основные операции

infix "+" (other: VECTOR [G]): VECTOR is

-- Поэлементное сложение текущего вектора с other

require ... do

...

end

... Прочие компоненты ...

invariant

non_negative_count: count >= 0

end

Применение инфиксной записи продиктовано соображениями удобства. Для удобства введены и синонимы в обозначении i -го компонента вектора: v.item (i) или просто v @ i .

Обратимся к функции " + ". Сначала сложение двух векторов кажется очевидным и состоящим в суммировании элементов на соответствующих местах. Общая его схема такова:

infix "+" (other: VECTOR [G]): VECTOR is

-- Поэлементное сложение текущего вектора с other

require

count = other.count

local

i: INTEGER

do

"Создать Result как массив из count элементов"

from i := 1 until i > count loop

Result.put(item (i) + other.item (i), i)

i := i + 1

end

end

Выражение в прямоугольнике - результат сложения i -го элемента текущего вектора с i -м элементом other . Процедура put сохраняет это значение в i -м элементе Result , и хотя она не показана в классе VECTOR , данная процедура в нем, безусловно, присутствует.