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

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

Пусть отношение "развернутый клиент" определяется следующим образом: класс 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 .

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

x := y

Это правило приводит к определению: