Читать онлайн «Основы объектно-ориентированного программирования». Страница 165

Два компонента (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

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

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, данная процедура в нем, безусловно, присутствует.

Рис. 16.5.  Поэлементное сложение векторов

Но подобная схема не работает! Операция +, которую мы определили для сложения векторов (VECTOR), здесь применяется к объектам совсем другого типа (G), являющегося родовым параметром. По определению, родовой параметр представлен неизвестным типом - фактическим параметром, появляющимся только тогда, когда нам понадобится для каких либо целей родовой класс. Процесс порождения класса при задании фактического родового параметра называется родовым порождением (generic derivation). Если фактическим параметром служит INTEGER либо иной тип (класс), содержащий функцию infix "+" правильной сигнатуры, корректная работа обеспечена. Но что если параметром станет ELLIPSE, STACK, EMPLOYEE или другой тип без операции сложения?

С прежними родовыми классами: контейнерами STACK, LIST и ARRAY - этой проблемы не возникало, поскольку их действия над элементами (типа G как формального параметра) были универсальны - операции (присваивание, сравнение) могли выполняться над элементами любого класса. Но для абстракций, подобных векторам, допускающих сложение, нужно ограничить круг допустимых фактических родовых параметров, чтобы быть уверенными в допустимости проектируемых операций.