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

Удобно несколько расширить нотацию. Иногда при проектировании класса, например E , хотелось бы установить, что все экземпляры класса должны быть развернутыми. Чтобы сделать это требование явным, следует объявить класс в следующей форме:

expanded class E feature

... Далее все аналогично любому другому классу ...

end

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

Определение: развернутый тип

Тип является развернутым в двух случаях:

Он задан в форме: expanded C

Он задан в форме E , где E - развернутый класс.

Объявление вида

x: expanded E

где E - развернутый класс, не будет ошибкой, поскольку эквивалентно

x: E

Таким образом, имеется два вида типов. Тип, не являющийся развернутым, является ссылочным типом. Эту терминологию можно использовать и для сущностей - ссылочные сущности и развернутые сущности. Аналогично и классы могут быть ссылочными и развернутыми.

Почему нам нужны развернутые типы? Они играют три важные роли:

[x].улучшают эффективность;

[x].обеспечивают лучшее моделирование;

[x].поддерживают базисные типы в унифицированной ОО-системе типов.

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

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

Рассмотрим два объявления атрибутов:

D1. ref: S

D2. exp: expanded S

Объявления появляются в классе C , предполагается также, что S это ссылочный класс. Объявление D1 отражает тот факт, что каждый экземпляр класса C "знает о" существовании некоторого экземпляра S (если только ref не является void ). Объявление D2 более требовательное: оно устанавливает тот факт, что каждый экземпляр класса C "содержит" экземпляр S . Даже если не думать о проблемах реализации, следует понимать, что речь идет о двух разных отношениях.

Отношение "содержит", поддерживаемое развернутыми типами, не допускает никакого разделениявстроенного объекта, в то время как отношение "знает о" допускает несколько ссылок, присоединенных к объекту.

Вот пример объявления класса:

class WORKSTATION feature

k: expanded KEYBOARD

c: expanded CPU

m: expanded MONITOR

n: NETWORK

...

end

Рабочая станция имеет клавиатуру, ЦПУ, монитор и подключена к сети. Клавиатура, ЦПУ и монитор являются частью данного компьютера и не могут разделяться двумя или несколькими рабочими станциями. Однако несколько рабочих станций подключены к одной и той же сети. Эти особенности проявляются в определении класса, использующем развернутые типы для первых трех атрибутов и ссылочный тип для атрибута "сеть".

Рис. 8.20. Отношения между объектами: «знает о» и «содержит»

Итак, концепция развернутого типа, появившаяся вначале как техника уровня реализации, фактически помогла описать некоторые из отношений, используемых при информационном моделировании. Отношение "содержит" и обратное к нему отношение "быть частью" являются центральными при построении моделей внешних систем; они появляются в методах анализа и при моделировании баз данных.

Третье важное приложение развернутых типов фактически является частным случаем второго. В предыдущей лекции подчеркивалась желательность унифицированной системы типов, включающей как встроенные, так и пользовательские типы. Пример REAL использовался, чтобы показать, как с помощью инфиксных и префиксных компонентов можно промоделировать понятие вещественного числа как класса. То же самое нетрудно проделать и для других базисных типов: BOOLEAN , CHARACTER , INTEGER , DOUBLE . Но проблема все же остается. Если классы рассматривать как ссылочные, то сущности базисных типов, такие как