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

Развернутые типы обеспечивают эквивалентный механизм. Мы можем, например, объявить класс CAR с компонентами развернутых типов: expanded ENGINE и expanded BODY . Другой способ основан на том, что агрегирование представляется отношением "развернутый клиент". Говорят, что класс C является развернутым клиентом класса S , если он содержит объявление компонента типа expanded S (или просто S , если S развернут). Одно из преимуществ такого модельного подхода в том, что развернутый клиент - это частный случай общего отношения "быть клиентом", так что можно использовать общие рамки и нотацию, комбинируя зависимости, подобные агрегированию с зависимостями, допускающими разделение. Примером могут служить с одной стороны - отношение между WORKSTATION и KEYBOARD , с другой - отношение между WORKSTATION и NETWORK .

Используя ОО-подход, можно избежать множественности отношений, используемых в литературе по информационному моделированию, - все покрывается двумя отношениями: клиент (развернутый или нет) и наследование.

Рассмотрим развернутый тип E (в любой форме) и развернутую сущность x типа E .

Так как значение x это всегда объект, то он не может быть void . Так что булево выражение:

x = Void

будет всегда вырабатывать значение false, и вызов в форме x.some_ feature (arg1, ...) никогда не приведет к возбуждению исключения из-за void цели, что могло случиться для ссылочной сущности.

Пусть объект O является значением x . Как и в случае не пустой ссылки, говорят, что x присоединено к O . Итак, для любой сущности, значение которой не void , можем говорить о присоединенном объекте, независимо от типа - ссылочного или развернутого - сущности.

Что можно сказать о создании развернутых объектов? Инструкцию:

create x

можно применить к развернутому x . Для ссылки x эффект достигался за три шага: (C1) создание нового объекта; (C2) инициализация его полей значениями по умолчанию; (C3) присоединение к x . Для развернутого x , шаг C1 неуместен, а шаг C3 бесполезен; так что единственный эффект состоит в инициализации полей значениями по умолчанию.

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

class F feature

u: BOOLEAN

v: INTEGER

w: REAL

x: C

y: expanded C

z: E

...

end

Класс E развернут, а класс C нет. Инициализация прямого экземпляра F включает установку поля u в false , v - в 0, w - в 0.0, x - ссылкой void , а экземпляры y и z станут экземплярами классов C и E соответственно, чьи поля будут инициализированы в соответствии со стандартными правилами. Этот процесс инициализации может быть рекурсивно продолжен, поскольку поля экземпляров C и E могут быть в свою очередь развернутыми.

Как можно было понять, использование развернутых типов требует введения некоторых ограничений, гарантирующих, что рекурсивный процесс создания будет конечным. Хотя, как отмечалось ранее, клиентские отношения в общем случае могут включать циклы, такие циклы не должны включать развернутые атрибуты. Например, недопустимо для класса C иметь атрибут типа expanded D , если класс D имеет атрибут типа expanded C . Это означало бы, что каждый объект C включал бы подобъект D , который бы включал подобъект C и так далее. Сформулируем правило "развернутого клиента", ранее введенное неформально:

Правило Развернутого Клиента

Пусть отношение "развернутый клиент" определяется следующим образом: класс C является развернутым клиентом класса S , если некоторый атрибут C является развернутым типом, основанным на классе S .

Тогда отношение развернутый клиент не может включать никаких циклов.

Другими словами, не может существовать множества классов A , B , C , ... N , где каждый последующий является развернутым клиентом предыдущего, а последний класс N является развернутым клиентом класса A . В частности, класс A не может иметь атрибут типа expanded A , так как это делало бы класс A своим развернутым клиентом.

Заключительное замечание ответит на вопрос, как сочетаются ссылки и подобъекты. Развернутый класс или развернутый тип, основанный на ссылочном классе, может иметь ссылочные атрибуты. Вполне допустимо, чтобы подобъект содержал ссылки на объекты, как показано на рисунке:

Рис. 8.21. Подобъект со ссылкой на другой объект

Приведенная ситуация предполагает следующие объявления:

Class COMPOSITE1 feature

other: SOME_TYPE

sub: expanded C

end

class C feature

ref: D

x: OTHER_TYPE; y: YET_ANOTHER_TYPE

end

class D feature

...

end

Каждый экземпляр класса COMPOSITE , такой как O_COMP на рис.8.21, имеет подобъект, ( OC на рисунке) содержащий ссылку ref , которая может быть присоединена к объекту ( OD на рисунке).

Но противоположная ситуация, где ссылка становится присоединенной к объекту, невозможна. Это будет следовать из правил присваивания и передаче аргументов, изучаемых в следующем разделе. Итак, структура времени выполнения никогда не может находиться в ситуации, показанной на рис.8.22, где OE содержит ссылку на OC , - подобъект O_CMP1 , и OC содержит ссылку на себя.

Рис. 8.22. Ссылка на подобъект

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

[x].С позиций реализации: механизм сборки мусора в этом случае должен быть готов справляться со ссылками на подобъекты, даже если в текущем выполнении будет всего несколько подобных ссылок или их вообще не будет. Это приводит к существенной потере производительности.

[x].С позиций моделирования: ссылки на подобъекты заставляют отказаться от упрощения описания системы, что можно сделать, определив единственную ссылочную единицу - объект.