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

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]. С позиций моделирования: ссылки на подобъекты заставляют отказаться от упрощения описания системы, что можно сделать, определив единственную ссылочную единицу - объект.

Присоединение: две семантики - ссылок и значений

В этом разделе рассматривается специальная информация, и он может быть пропущен при первом чтении.

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

Присоединение

Семантика присваивания, как отмечалось, распространяется еще на одну операцию - передачу аргумента при вызове подпрограмм. Предположим, существует подпрограмма (процедура или функция) в форме:

r (..., x: SOME_TYPE, ...)

Здесь сущность x это один из формальных аргументов r. Рассмотрим теперь некоторый вызов r в любой из двух возможных форм - квалифицированный или неквалифицированный вызов:

r (..., y, ...)

t.r (..., y, ...)

Выражение y является фактическим аргументом, передаваемым формальному аргументу x.