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

r: REAL

будут в период выполнения ссылками на возможные объекты, содержащие значение (в данном случае REAL ). Это неприемлемо: чтобы соответствовать общей практике программирования значение должно быть не ссылкой, а самим вещественным числом. Решение проблемы немедленно следует из обсуждения - класс REAL следует объявить как развернутый. Его объявление должно быть таким:

expanded class REAL feature

... Объявления компонент такие же как и ранее ...

end

Все другие базисные типы объявляются подобным образом как развернутые.

В некоторых областях информатики - базах данных, моделировании, анализе требований - разработана классификация отношений, имеющих место между элементами моделируемой системы. В этих контекстах часто встречается отношение "агрегирования" (aggregation), выражающее тот факт, что каждый объект некоторого типа является агрегатом - содержит в своем составе ноль или более объектов, каждый из которых имеет свой собственный тип. Например: автомобиль является агрегатом, содержащим мотор, кузов и другие детали.

Развернутые типы обеспечивают эквивалентный механизм. Мы можем, например, объявить класс 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 и так далее. Сформулируем правило "развернутого клиента", ранее введенное неформально: