Совместное использование и репликация

Совместное использование и репликация

Из приведенного примера вытекает основная проблема дублируемого наследования: каков смысл компонентов дублируемого потомка (FRENCH_US_DRIVER), полученных от дублируемого предка (DRIVER)?

Рассмотрим компонент age. Он наследуется от обоих потомков DRIVER, так что, на первый взгляд, возникает конфликт имен, требующий переименования. Однако такое решение было бы неадекватно проблеме, так как реального конфликта здесь нет - атрибут age унаследованный от DRIVER, задает возраст водителя, и он один и тот же для всех потомков (если только не менять свои данные в зависимости от страны пребывания). То же относится к процедуре pass_birthday.

Внимательно перечитайте правило о конфликте имен:

Класс, наследующий от разных родителей различные компоненты с идентичным именем, некорректен.

Компоненты age (также как и pass_birthday), наследованные классом FRENCH_US_DRIVER от обоих родителей, не являются "различными", поэтому реального конфликта не возникает. Заметьте, неоднозначность могла бы возникнуть лишь в случае переопределения компонента в одном из классов. Чуть позже мы покажем, как справиться с этой проблемой, а пока предположим, что переопределений не происходит.

Если компонент дублируемого предка под одним и тем же именем наследуется от двух и более родителей, он становится одним компонентом дублируемого потомка. Этот случай будем называть совместным использованием компонента (sharing).

Всегда ли применяется совместное использование? Нет. Рассмотрим компоненты address, pay_fee, violation_count. Обращаясь в службу регистрации автотранспорта в разных странах, водители скорее всего будут указывать разные адреса и по-разному платить ежегодные сборы. Впрочем, и нарушения правил тоже будут различны. Каждый из таких компонентов, следует представить в дублируемом потомке двумя разными компонентами. Данный случай будем называть репликацией (replication).

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

Чтобы совместно использовать один из компонентов, достаточно под одним именем унаследовать исходную версию этого компонента от обоих родителей. Но как реализовать репликацию? Делая все наоборот: породив один компонент под двумя разными именами.

Эта идея не противоречит общему правилу, согласно которому каждое имя в классе служит обозначением лишь одного компонента. Поэтому репликация компонента означает переименование при наследовании.

Правило дублируемого наследования

У дублируемого потомка версии дублируемого компонента, наследуемые под одним и тем же именем, представляют один компонент. Версии, наследуемые под разными именами, представляют разные компоненты, являясь репликацией оригинала дублируемого предка.

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

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

Правило придает желаемую гибкость процессу объединения классов. Вот как может выглядеть класс FRENCH_US_DRIVER:

class FRENCH_US_DRIVER inherit

FRENCH_DRIVER

rename

address as french_address,

violation_count as french_violation_count,

pay_fee as pay_french_fee

end

US_DRIVER

rename

address as us_address,

violation_count as us_violation_count,

pay_fee as pay_us_fee

end

feature

...

end

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

Следующая глава >

Похожие главы из других книг:

Совместное использование событий и мьютексов

Из книги автора

Совместное использование событий и мьютексов Далее показано, как обеспечить совместное использование мьютексов и событий путем обобщения программы 8.2, представляющей описанную ниже ситуацию, с которой нам еще не раз предстоит столкнуться. Примечание. Это обсуждение в


Совместное использование объектов ядра приложениями и службами

Из книги автора

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


Совместное использование HTML и JavaScript

Из книги автора

Совместное использование HTML и JavaScript Прежде всего надо рассмотреть тег <SCRIPT>. Этот тег служит для вставки скриптов в HTML-код страницы. Его формат:<SCRIPT [language="{Язык программирования, на котором написан скрипт}"] [src="{Адрес файла со скриптом}"]>. . . Текст скрипта</SCRIPT>Текст


Совместное использование PostScript-принтеров

Из книги автора

Совместное использование PostScript-принтеров В ходе предыдущего обсуждения не затрагивался вопрос об использовании драйверов. Этот вопрос чрезвычайно важен для разделения принтеров в системе Samba; драйверы принтеров часто становятся источником проблем. В системе Windows


Совместное использование принтеров, не поддерживающих PostScript

Из книги автора

Совместное использование принтеров, не поддерживающих PostScript Существуют два способа настройки Samba для работы с принтерами, не поддерживающими PostScript. Первый способ заключается в использовании PostScript-драйвера на клиентской машине и настройке очереди печати Linux для


Глава 8 Совместное использование файлов с помощью NFS

Из книги автора

Глава 8 Совместное использование файлов с помощью NFS Протоколы Server Message Block (SMB)/Common Internet Filesystem (CIFS), рассмотренные в предыдущей главе, очень удобны для организации совместного доступа к файлам и принтерам клиентов, работающих под управлением DOS, Windows, OS/2 и многих других


Глава 9 Совместное использование принтеров

Из книги автора

Глава 9 Совместное использование принтеров Система печати, используемая в Linux, первоначально была разработана для BSD UNIX. Эта система, которую также называют по имени ее основного компонента LPD (Line Printer Daemon — демон принтера), намного проще, чем системы печати Windows и MacOS, и в то


4.26 Совместное использование сетевого интерфейса

Из книги автора

4.26 Совместное использование сетевого интерфейса Как уже отмечалось, несложно найти локальные и региональные сети, использующие одновременно несколько протоколов. На практике один сетевой узел иногда посылает и принимает данные по нескольким протоколам через единый


12.3. Совместное использование каталогов в Linux Mandrake

Из книги автора

12.3. Совместное использование каталогов в Linux Mandrake Конфигуратор diskdrake-fileshare позволяет очень быстро настроить пакет Samba для разрешения совместного использования каталогов («расшаривания» каталогов). Убедитесь, что запущены сервисы nfs и smb, если это не так, запустите их:# service


Совместное использование gds32.dll, InterBase.msg и mscvrt.dll

Из книги автора

Совместное использование gds32.dll, InterBase.msg и mscvrt.dll Представьте ситуацию, когда на одном компьютере оказались два приложения, использующие клиент InterBase. Первое приложение успешно инсталлировалось, установив вместе с собой InterBase-клиента. Второе приложение в процессе


Совместное использование файлов

Из книги автора

Совместное использование файлов InterBase-сервер может быть встроен не только в ваше серверное программное обеспечение, поэтому основные файлы, входящие в состав его установки, надо зарегистрировать в Windows. Регистрация происходит точно так же, как описано выше в разделе


У9.3 Совместное использование стека достижимых элементов

Из книги автора

У9.3 Совместное использование стека достижимых элементов (Это упражнение подразумевает знакомство с результатами лекции 18) Перепишите компонент available, задающий стек достижимых элементов при подходе на уровне компонентов. Единственный стек должен совместно


У9.4 Совместное использование

Из книги автора

У9.4 Совместное использование (Это упражнение подразумевает, что вы выполнили предыдущее и прочитали все лекции, включая лекцию 18) Можно ли сделать available стек разделяемым всеми связными списками произвольных


Совместное использование образцов и библиотек

Из книги автора

Совместное использование образцов и библиотек В свете последних тенденций глобализации и международного разделения труда будет нелишним разговор о совместном использовании образцов и целых библиотек. Речь в данном разделе пойдет о том, как сделать наши образцы


1.10.7. Совместное использование файлов и папок

Из книги автора

1.10.7. Совместное использование файлов и папок На каждом Маке в окне жесткого диска находится папка Пользователи (Users), в которой хранятся домашние папки всех пользователей данного компьютера. Раскрыв любую из них, кроме своей домашней папки (на рис. 1.116 пользователь sn