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

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

Конфликт переопределений

Пока в ходе наследования мы меняли лишь имена. А что, если промежуточный предок, такой, как