Фиксированная семантика компонентов copy, clone и equality
Чаще всего замороженные (frozen) компоненты применяются в операциях общего назначения, подобных тем, что входили в состав класса GENERAL. Так, есть две версии базовой процедуры копирования:
copy, frozen standard_copy (other: ...) is
-- скопировать поля other в поля текущего объекта.
require
other_not_void: other /= Void
do
...
ensure
equal (Current, other)
end
Два компонента (copy и standard_copy) описаны как синонимы. Правила разрешают совместно описывать два компонента класса, если они имеют общее определение. Заметьте, в данном случае только один из компонентов допускает повторное объявление, второй - заморожен. В итоге потомки вправе переопределить copy, что необходимо, например классам ARRAY и STRING, которые сравнивают содержимое, а не значение указателей. Однако параллельно удобно иметь и замороженный вариант компонента для вызова при необходимости исходной операции - standard_copy.
Компонент 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
-- Количество элементов