Ненавязчивое дублирующее наследование

На практике не столь часто встречаются примеры, подобные "межконтинентальным" водителям, в которых нужны и репликация компонентов, и их совместное применение. Они не для новичков. Следует приобрести опыт, чтобы браться за них.

Иначе в попытке использовать дублирующее наследование "в лоб", можно лишь все усложнить, когда это и не нужно.

Рис. 15.19.  Избыточное наследование

На рисунке показана типичная ошибка начинающих (или рассеянных разработчиков): класс D объявлен наследником B , ему нужны также свойства класса A , но B сам является потомком A . Забыв о транзитивности наследования, разработчик пишет:

class D ... inherit

B

A

...

В итоге возникает дублируемое наследование. Его избыточность очевидна. Впрочем, при надлежащем соблюдении принятых соглашений все компоненты классов (при сохранении их имен) будут использоваться совместно, новых компонентов не появится, и дополнительных издержек не будет. Даже если в B часть имен атрибутов меняется, единственным следствием этого станет лишь некоторый расход памяти.

Из этого есть только одно исключение: случай, когда B переопределяет один из компонентов A , что приведет к неоднозначности в D . Но тогда, как будет показано ниже, компилятор выдаст сообщение об ошибке, предлагая выбрать в D один из двух вариантов компонента.

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

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

Правило переименования

В этом разделе мы не введем никаких новых понятий, а лишь точнее сформулируем известные правила и приведем пример, призванный пояснить сказанное.

Начнем с запрета возникновения конфликта имен:

Определение: финальное имя

Финальным именем компонента класса является:

[x]. Для непосредственного компонента (объявленного в самом классе) - имя, под которым он объявлен.

[x]. Для наследуемого компонента без переименования - финальное имя компонента (рекурсивно) в том родительском классе, от которого оно унаследовано.

[x]. Для переименованного компонента - имя, полученное при переименовании.

Правило одного имени

Разные эффективные компоненты одного класса не могут иметь одно и то же финальное имя.

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

Ключевым в тексте правила является слово "разные ". Если под одним именем мы наследуем от родителей компонентов их общего предка, действует принцип совместного использования компонентов: наследуется один компонент , и конфликта имен не возникает.

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

Приведенные правила просты и интуитивны. Чтобы в последний раз нам убедиться в их правильном понимании, построим простой пример, демонстрирующий допустимые и недопустимые варианты наследования.

Рис. 15.20.  Два варианта наследования

class A feature

this_one_OK: INTEGER

end

class B inherit A feature

portends_trouble: REAL

end

class C inherit A feature

portends_trouble: CHARACTER

end

class D inherit

-- Это неправильный вариант!

B

C

end

Класс D наследует this_one_OK дважды, один раз от B , другой раз - от C . Конфликта имен не возникает, поскольку данный компонент будет использоваться совместно. На самом деле, это - один компонент предка A .

Два компонента portend_trouble ("предвещающие беду") заслуженно получили такое имя. Они различны, потому их появление в D ведет к конфликту имен, делая класс некорректным. (У них разные типы, но и одинаковые типы никак не повлияли бы на ход нашего обсуждения.)

Переименовав один из компонентов, мы с легкостью сделаем D корректным:

class D inherit

-- Этот вариант класса теперь полностью корректен.

B

rename portends_trouble as does_not_portend_trouble_any_more end

C

end