Техника наследования

Замороженные компоненты

При обсуждении идеи наследования неоднократно подчеркивался принцип Открыт-Закрыт - право, взяв компонент класса-родителя, переопределить его, возложив на него иные задачи. Могут ли появиться причины запрета такой возможности?

Запрет повторного объявления

Обсуждение утверждений в начале лекции дало нам теоретическое понимание сути переопределений. Часть "Открыт" принципа Открыт-Закрыт дает возможность изменять компоненты потомков, но под контролем утверждений. Разрешены лишь те повторные объявления, для которых реализация согласуется со спецификацией, заданной предусловием и постусловиям оригинала.

В ряде случаев клиентам класса и клиентам классов потомков нужна гарантия, что компонент не только соблюдает спецификацию, но и пользуется в точности исходной реализацией. Достичь этого можно лишь "заморозив" его реализацию - полностью запретив переопределение компонента. Подобную возможность дает простая языковая конструкция:

frozen feature_name ... is... Остальные объявления - как обычно...

При таком описании ни один из потомков класса не может включать данный компонент в предложения redefine и undefine ни под своим, ни под любым другим именем (смена имен, конечно же, по-прежнему разрешена). Отложенный компонент по своей сути должен быть переопределен и, следовательно, не может быть заморожен.

Фиксированная семантика компонентов 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 в редких, но важных для себя случаях, когда это действительно необходимо (для обеспечения точного соответствия семантике исходной реализации), и пусть ваш язык и ваш компилятор делают свою работу.