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

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

b: BOOK3

не влечет за собой создание объекта во время выполнения, это происходит, когда некий элемент системы выполнит операцию

create b

Это может показаться удивительным. Разве объявления b недостаточно для создания объекта? Что хорошего в объявлении, если объект не создается?

Достаточно минуты размышления для понимания того, что разделение объявления и создания объекта является единственно разумным решением.

Первый аргумент - reductio ad absurdum(доведение до абсурда). Предположим, что начата обработка объявления и немедленно создается соответствующий объект. Но это экземпляр класса BOOK3 , имеющий атрибут author ссылочного типа WRITER , значит поле author - ссылка, для которой опять нужно создавать объект. Этот объект вновь содержит ссылочные поля, требуется опять делать то же самое и начинается длинный путь рекурсивного создания объектов.

Этот аргумент еще более убедителен для таких классов как PERSON1 , содержащих ссылки на себя:

class PERSON1 feature

name: STRING

loved_one, landlord: PERSON1

end

Появление каждого экземпляра PERSON1 повлечет за собой создание двух других таких объектов (соответствующих loved_one и landlord ) и начнется бесконечный цикл. Такие прямые или косвенные циклические ссылки не экзотика - они часто встречаются и необходимы.

Другой аргумент следует из обсуждения роли объектной технологии как мощного метода моделирования. Если для каждого ссылочного поля будет создаваться новый объект, то не было бы возможности выделить пустые ссылки и множественные ссылки на один и тот же объект. И то, и другое необходимо для реалистичного моделирования систем:

[x].В некоторых случаях требуется, чтобы ссылка не была связана ни с каким объектом. Примером может служить пустая ссылка author для обозначения неизвестного автора.

[x].В других случаях, в соответствии с моделью две ссылки должны быть присоединены к одному объекту. (См. рис.8.7) В примере с циклическими ссылками присутствовали поля loved_one двух персон PERSON1 , присоединенные к одному и тому же объекту. Не имело бы смысла создание своего объекта для каждого из этих полей. Все, что требуется, - это операция присваивания (рассмотрена далее в этой лекции) для присоединения ссылки к уже существующему объекту. В еще большей степени это соображение применимо для ссылки на себя (поле landlord верхнего объекта в том же примере).

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

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

Для использования инициализации, отличной от предопределенной умолчанием, необходимо класс снабдить одной или несколькими процедурами создания. Такие процедуры должны быть перечислены в предложении, начинающимся ключевым словом creationв начале класса перед первым предложением feature. Схема такова:

indexing

...

class C creation

p1, p2, ...

feature

... Объявления компонент, включая реализацию процедур p1, p2, ...

end

Соответствующая инструкция создания в этих случаях имеет другую форму:

create x.p (...)

где p одна из процедур создания перечисленных в разделе creation, и в круглых скобках (...) перечисляются фактические аргументы p . Результатом является создание объекта с использованием значений по умолчанию, как и ранее, а затем вызов p с заданными аргументами. Такая инструкция является комбинацией инструкции создания и вызова процедуры и называется порождающим вызовом (creation call). (Оригинальная версия класса POINT приведена в лекции 7)

В качестве примера добавим две процедуры создания в класс POINT , что позволит клиентам при создании новой точки указывать ее начальные координаты - декартовы или полярные. Введем процедуры создания: make_cartesian и make_polar . Вот схема:

class POINT1 creation

make_cartesian, make_polar

feature

... Компоненты из предыдущей версии класса:

x, y, ro, theta, translate, scale, ...

feature {NONE} - Этот вариант экспорта рассмотрен ниже.

make_cartesian (a, b: REAL) is

-- Инициализация точки с декартовыми координатами a и b.

do

x := a; y := b

end

make_ polar (r, t: REAL) is

-- Инициализация точки с полярными координатами r и t.

do

x := r * cos (t); y := r * sin (t)

end

end

Для такого класса клиент будет создавать точки инструкциями вида:

create my_point.make_cartesian (0, 1)

create my_point.make_polar (1, Pi/2)

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

Эффект порождающего вызова

Рассмотрим порождающий вызов в форме create x.p(...) .

Пусть тип цели x это ссылочный тип, основанный на классе C , p(...) - процедура создания класса C , с заданным списком фактических аргументов. Эффект вызова состоит в выполнении следующих четырех шагов: