Основы объектно-ориентированного программирования
Шрифт:
В данном случае смена имен происходит на последнем этапе - у дублируемого потомка, но полное или частичное переименование могло быть выполнено и родителями - US_DRIVER и FRENCH_DRIVER. Важно, что будет в конце, - получит ли компонент при дублируемом наследовании одно или разные имена.
Компоненты age и pass_birthday переименованы не были, а потому, как мы и хотели, они используются совместно.
Реплицируемый атрибут, скажем, address, в каждом экземпляре класса FRENCH_US_ DRIVER будет представлен несколькими полями данных. Тогда при условии, что эти классы содержат только указанные нами компоненты, их экземпляры будут выглядеть как на рис. 15.18 .
Рис. 15.17. Совместное использование и репликация
Рис. 15.18. Репликация атрибутов
(Организация FRENCH_DRIVER и US_DRIVER аналогична организации DRIVER, см. рисунок.)
Особенно важным в реализации классов является умение избегать репликации совместно используемых компонентов, например age из FRENCH_US_DRIVER. Не имея достаточно опыта, можно легко допустить такую ошибку и реплицировать все поля класса. Тратить память впустую недопустимо, так как по мере спуска по иерархии "мертвое" пространство будет лишь возрастать, что приведет к катастрофически неэффективному расходованию ресурсов. (Помните, что каждый атрибут во время выполнения потенциально представлен во многих экземплярах класса и его потомков.)
Механизм компиляции, описанный в конце этой книги, на деле дает гарантию того, что потерь памяти на атрибуты не будет, - концептуально совместно используемые (shared) атрибуты класса будут располагаться в общей для них (shared) физической памяти. Это - один из сложнейших компонентов реализации наследования и вызовов при динамическом связывании. Ситуация усложняется еще и тем, что подобное дублируемое наследование не должно влиять на производительность, что означает:
[x]. нулевые затраты на поддержку универсальности;
[x]. низкие, ограниченные константой, затраты на динамическое связывание (не зависящие от наличия в системе дублируемого наследования классов).
Поскольку существует реализация, отвечающая этим целям, то и в любой системе техника дублируемого наследования не должна требовать значительных издержек.
| Дублируемое наследование в С++ следует другому образцу. Уровень, на котором принимается решение, разделять или дублировать компоненты, - это класс. Поэтому при необходимости дублирования одного компонента, приходится дублировать все. В Java эта проблема исчезает, поскольку запрещено множественное наследование. |
Ненавязчивое дублирующее наследование
На практике не столь часто встречаются примеры, подобные "межконтинентальным" водителям, в которых нужны и репликация компонентов, и их совместное применение. Они не для новичков. Следует приобрести опыт, чтобы браться за них.
Иначе в попытке использовать дублирующее наследование "в лоб", можно лишь все усложнить, когда это и не нужно.
Рис. 15.19. Избыточное наследование
На рисунке показана типичная ошибка начинающих (или рассеянных разработчиков): класс D объявлен наследником B, ему нужны также свойства класса A, но B сам является потомком A. Забыв о транзитивности наследования, разработчик пишет:
В итоге возникает дублируемое наследование. Его избыточность очевидна. Впрочем, при надлежащем соблюдении принятых соглашений все компоненты классов (при сохранении их имен) будут использоваться совместно, новых компонентов не появится, и дополнительных издержек не будет. Даже если в B часть имен атрибутов меняется, единственным следствием этого станет лишь некоторый расход памяти.
Из этого есть только одно исключение: случай, когда B переопределяет один из компонентов A, что приведет к неоднозначности в D. Но тогда, как будет показано ниже, компилятор выдаст сообщение об ошибке, предлагая выбрать в D один из двух вариантов компонента.
Избыточное, хотя и безвредное наследование может произойти, если A– это класс, реализующий универсальные функции, например ввода-вывода, необходимые B и D. В этом случае достаточно объявить D наследником B. Это автоматически делает D потомком A, что позволяет обращаться ко всем нужным функциям. Избыточное наследование не нанесет никакого вреда, оставшись практически без последствий.
| Такие случаи "безвредного" наследования могут происходить при порождении от универсальных классов ANY и GENERAL, речь о которых пойдет в следующей лекции. |
Правило переименования
В этом разделе мы не введем никаких новых понятий, а лишь точнее сформулируем известные правила и приведем пример, призванный пояснить сказанное.
Начнем с запрета возникновения конфликта имен:
Определение: финальное имя
Финальным именем компонента класса является:
[x]. Для непосредственного компонента (объявленного в самом классе) - имя, под которым он объявлен.
[x]. Для наследуемого компонента без переименования - финальное имя компонента (рекурсивно) в том родительском классе, от которого оно унаследовано.
[x]. Для переименованного компонента - имя, полученное при переименовании.
Правило одного имени
Разные эффективные компоненты одного класса не могут иметь одно и то же финальное имя.
Конфликт имен происходит в том случае, когда два разных по сути компонента, оба эффективные (реализованные), имеют одно финальное имя. Такой конфликт делает класс некорректным, однако ситуацию легко исправить, добавив надлежащее предложение переименования.
Ключевым в тексте правила является слово "разные". Если под одним именем мы наследуем от родителей компонентов их общего предка, действует принцип совместного использования компонентов: наследуется один компонент, и конфликта имен не возникает.