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

Работа с объектами и ссылками

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

Динамическое создание и повторное связывание

Что не было показано при описании структуры объектов периода выполнения, так это в высшей степени динамичная природа настоящей ОО-модели. Статическая и ориентированная на стеки политика управления объектами характерна для языков уровня Fortran и Pascal соответственно. Противоположной является политика в настоящем ОО-окружении, позволяющая создавать объекты в период выполнения, когда в них возникает потребность. Какому образцу (типу) соответствуют создаваемые объекты, как правило, невозможно предсказать при статической проверке программного текста.

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

Следующий раздел посвящен механизмам, необходимым для создания объектов и манипулирования их полями, в частности, ссылками.

Инструкция создания

Рассмотрим создание экземпляра класса BOOK3. Это возможно только с помощью подпрограммы класса, являющегося клиентом BOOK3, как, например:

class QUOTATION feature
source: BOOK3
page: INTEGER
make_book is
-- Создание объекта BOOK3 и присоединение его к source.
do
... См. ниже ...
end
end

Этот класс описывает цитирование книги в других публикациях. Он содержит два поля: ссылку на цитируемую книгу и число страниц, содержащих ссылки на нее.

Механизм создания экземпляра QUOTATION (скоро он будет рассмотрен) предусматривает инициализацию всех его полей. Правило инициализации по умолчанию определяет, что любое ссылочное поле (в данном примере - поле, соответствующее атрибуту source) после инициализации должно содержать пустую ссылку. Другими словами, создание объекта типа QUOTATION не сопровождается созданием объекта типа BOOK3.

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

make_book is
-- Создание объекта BOOK3 и присоединение его к source.
do
create source
end

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

Сущность x, именованная в инструкции (в данном примере source), называется целью (target) инструкции создания.

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

Результат базовой инструкции создания

Эффект инструкции создания вида create x , где тип цели x является ссылочным типом, основанном на классе C, состоит в выполнении трех следующих действий:

[x]. (C1) Создание нового экземпляра C(набора полей, по одному на каждый атрибут C). Пусть OC - это новый экземпляр.

[x]. (C2) Инициализация каждого поля OC соответствующими стандартными значениями по умолчанию.

[x]. (C3) Присоединение значения x (ссылки) к OC.

На этапе C1 создается экземпляр C. На этапе C2 устанавливаются предопределенные значения всех полей, зависящие от типа соответствующего атрибута:

Значения по умолчанию при инициализации

Для ссылок значение по умолчанию - пустая ссылка.

Для полей BOOLEAN значение по умолчанию - False.

Для полей CHARACTER значение по умолчанию - символ null.

Для чисел (типов INTEGER, REAL или DOUBLE) значение по умолчанию - ноль в соответствующем данному типу представлении.

Итак, для цели source типа BOOK3 в соответствии с объявлением класса

class BOOK3 feature
title: STRING
date, page_count: INTEGER
author: WRITER
end

результатом инструкции создания create source, выполняемой при вызове процедуры make_book класса QUOTATION, будет объект изображенный на рис.8.10.

Рис. 8.10.  Созданный и инициализированный объект

После инициализации значения целочисленных полей равны нулю. Ссылочное поле author и поле title типа STRING, содержат пустые ссылки. Тип STRING, о котором ничего не говорится в правилах инициализации, двойственен, - фактически являясь ссылочным типом, он рассматривается во многих ситуациях как базовый тип. (О строках см. лекцию 13)

Общая картина

Важно проследить за последовательностью происходящих событий. Для рассмотренного выше экземпляра BOOK3 происходит следующее:

[x]. (B1) Создан экземпляр QUOTATION. Пусть Q_OBJ - этот экземпляр и имеется сущность a, значение которой ссылка, присоединенная к Q_OBJ.

[x]. (B2) Спустя некоторое время после B1 вызов вида a.make_book приводит к выполнению процедуры make_book с Q_OBJ в качестве цели.

Правомерен вопрос - как будет создан сам Q_OBJ (шаг B1)? Это, оставляя проблему, отодвигает ее вглубь. Но к этому моменту мы уже знаем ответ на этот вопрос: все возвращается к первопричине - Большому Взрыву. Для выполнения системы необходимо снабдить ее корневым классом и процедурой этого класса, названной процедурой создания. В начале выполнения автоматически создается один объект - корневой объект - экземпляр корневого класса. Корневой объект является единственным объектом, не создаваемым инструкциями программного текста; он приходит извне, как objectus ex machine (объект от машины). Начав с одного, провидением посланного объекта, далее уже программа может создавать объекты нормальным путем через подпрограммы, выполняющие инструкции создания. Первой выполняемой подпрограммой является процедура создания, автоматически применяемая к корневому объекту. Не всегда, но чаще всего она содержит по крайней мере одну инструкцию создания, что в предыдущей лекции называлось началом грандиозного фейерверка, процесса, создающего столько новых объектов, сколько нужно текущему выполнению.

Для чего необходимо явное создание объектов?

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

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 верхнего объекта в том же примере).

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

Оглавление книги