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

Операции над ссылками

Мы уже знакомы с одним из способов изменения значения ссылки x: использование инструкции создания в форме create x , позволяющей создать новый объект и присоединить его к ссылке. Имеются и другие интересные операции, доступные при работе со ссылками.

Присоединение ссылки к объекту

Классы, появляющиеся в этой лекции, не имели подпрограмм - у них были только атрибуты. Как отмечалось, такие классы почти бесполезны, так как у них нет способа изменить значение атрибутов. Необходимы способы модификации ссылок, не использующие при этом инструкций в духе языков Pascal-C-Java-C++, подобных присваиванию: my_beloved.loved_one := me (напрямую изменяющих у объекта поле loved_one), что нарушает принцип скрытия информации и синтаксически некорректно в нашей нотации.

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

class PERSON2 feature
name: STRING
loved_one, landlord: PERSON2
set_loved (l: PERSON2) is
-- Присоединить поле loved_one текущего объекта к объекту l.
do
loved_one := l
end
end

Процедура set_loved присваивает ссылочному полю loved_one текущего экземпляра PERSON2 значение другой ссылки l. Ссылочное присваивание (левая и правая части являются ссылками) присваивает значение источника (правой части) целевой ссылке (слева).

Эффект ссылочного присваивания очевиден: целевая ссылка становится присоединенной к объекту, к которому присоединен источник - или становится void, если такое значение имеет источник. Предположим, например, что мы начинаем с ситуации, изображенной на рис.8.12 , где поля landlord и loved_one всех изображенных объектов пока пусты.

Рис. 8.12.  Перед присваиванием ссылке

Предположим, что выполняется вызов процедуры:

a.set_loved (r)

Сущность a присоединена к объекту O1, а сущность r - к O3. В результате выполнения процедуры set_loved выполнится присваивание:

loved_one := l

Здесь в роли текущего объекта выступает объект O1, сущности l и r имеют одинаковое значение - ссылки на объект O3. В результате изменится значение поля loved_one объекта O1 - ссылка присоединится к другому объекту O3, как показано на следующем рисунке:

Если бы r было пустой ссылкой, то такой же в результате присваивания стала бы и ссылка в поле loved_one объекта O1.

Рис. 8.13.  После присваивания ссылки

Сравнение ссылок

Наряду с присваиванием возникает необходимость и в тесте - проверить, присоединены ли две ссылки к одному и тому же объекту. Для этого есть оператор эквивалентности =.

Если x и y - сущности ссылочного типа, то выражение:

x = y

истинно тогда и только тогда, когда обе ссылки пусты или присоединены к одному и тому же объекту. Противоположный оператор "не эквивалентно" записывается как /=.

Выражение:

r = a.loved_one

истинно в ситуации, представленной на рис.8.13 и ложно для ситуации рис.8.12 .

Заметьте, в операциях эквивалентности сравниваются ссылки, а не объекты, к которым они присоединены. Так что если две ссылки присоединены к разным объектам, результатом операции эквивалентности будет false, даже если объекты имеют все поля с одинаковыми значениями. Операции, сравнивающие объекты, а не ссылки, будут введены позднее.

Значение void

Получить пустую ссылку достаточно просто - при инициализации по умолчанию все ссылки пусты. Однако удобно иметь специальное имя для ссылки, доступной в любом контексте и имеющей значение void . Предопределенный компонент

Void

играет эту роль.

Обычно компонент Void используется в тестах, проверяющих пустоту ссылок:

if x = Void then ...

и для того, чтобы присвоить некоторой ссылке это значение:

x := Void

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

Рис. 8.14.  Отсоединение ссылки от объекта

Клонирование и сравнение объектов

Ссылочное присваивание приводит к тому, что две или несколько ссылок присоединяются к одному объекту. Иногда необходима другая форма присваивания, в результате которой мы хотим получить не копию ссылки, а копию объекта. Эта цель достигается при вызове функции клонирования clone.

Если y присоединено к объекту OY, выражение

clone (y)

означает создание нового объекта OX , такого, что он имеет те же поля, что и OY, и все соответствующие поля имеют идентичные значения. Если y равно void, то значение clone (y) также void.

Скопировать присоединенный к y объект и связать копию со ссылкой x позволяет присваивание:

[1]
x := clone (y)

Вот иллюстрация этого механизма:

Рис. 8.15.  Клонирование объекта

Наряду со сравнением ссылок необходим механизм, позволяющий сравнивать объекты. Этой цели служит функция equal . Вызов:

equal (x, y)

возвращает значение true, если и только если x и y оба имеют значение void или присоединены к двум объектам с идентичными полями. После выполнения присваивания с клонированием [1], состояние, непосредственно следующее за присваиванием, удовлетворяет equal (x, y).

Копирование объектов

Функция clone создает новую копию существующего объекта. Иногда целевой объект уже существует, и все, что необходимо, это скопировать значения полей. Процедура copy выполняет эту работу. Она вызывается обычным образом:

x.copy (y)

Сущности x и y должны быть одного и того же типа; эффект от выполнения - копирование полей объекта, присоединенного к y, в соответствующие поля объекта, присоединенного к x.

Как и во всех вызовах компонента, вызов copy требует, чтобы целевой объект x был не пуст. Дополнительно требуется, чтобы и y был не пуст. Эта неспособность иметь дело с пустыми ссылками отличает copy от clone.

Процедура copy может считаться более фундаментальной, чем функция clone в том смысле, что, по меньшей мере, для класса без процедуры создания можно выразить clone в терминах copy следующим образом:

clone (y: SOME_TYPE) is
-- Void если y равно void; иначе дублировать присоединенный к y объект
do
if y /= Void then
create Result --Правильно только в отсутствие процедур создания
Result.copy (y)
end
end

При вызове функции сущность Result автоматически инициализируется в соответствии с общими правилами для атрибутов. Вот почему нет необходимости в ветви else условного оператора: Result инициализируется значением Void , так что результатом функции будет void , если значение y это void.

Глубокое клонирование и сравнение

Формы копирования и сравнения, реализуемые подпрограммами clone, equal и copy , называются поверхностными, поскольку они работают с объектами только на первом уровне, никогда не пытаясь следовать вглубь по ссылкам. Возникает необходимость для глубоких вариантов этих операций, рекурсивно дублирующих полную структуру.

Для понимания разницы рассмотрим пример, показанный на рис.8.16. Предположим, что мы начинаем в начальном состоянии A, где сущностьaприсоединена к объекту O1.

Рис. 8.16.  Различные формы присваивания и клонирования

Рассмотрим простое присваивание ссылки:

b := a

В состоянии B, показанном на рисунке, цель b в результате присваивания присоединена к объекту O1, к которому присоединен источник a. Никаких новых объектов не создается.

Далее рассмотрим операцию клонирования:

c := clone (a)

Эта инструкция, как показывает раздел C нашего рисунка, создает новый объект O4, с полями, идентичными полям объекта O1. Будут скопированы два ссылочных поля, и значения ссылок будут указывать на те же объекты O1 и O3, как и поля оригинального объекта O1. Но, заметьте, не происходит дублирования самого объекта O3, и никакого другого объекта помимо дублирования O1. По этой причине базисная операция clone называется поверхностным клонированием, - она останавливается на первом уровне объектной структуры.

В некоторых ситуациях вы, возможно, захотите пойти дальше и дублировать структуру рекурсивно без введения разделяемых ссылок. Функция глубокого клонирования deep_clone позволяет достичь цели. Процесс создания deep_clone (y) рекурсивно следует за всеми ссылочными полями, содержащимися в объекте, дублируя полную структуру. (Если y это void, то и результат будет также void.) Эта функция будет, конечно же, правильно обрабатывать циклические ссылочные структуры.

Нижняя часть на рисунке - раздел D - иллюстрирует выполнение этой операции:

d := deep_clone (a)

В этом случае не появляются новые разделяемые ссылки. Все объекты, прямо или косвенно доступные объекту O1, будут дублированы, создавая новые объекты O5, O6 и O7. Нет никаких связей между старыми объектами (O1, O2 и O3) и новыми. Объект O5, дублирующий O1, имеет собственные ссылки на себя.

Так же, как необходимы операции глубокого и поверхностного клонирования, необходимо иметь глубокий вариант эквивалентности. Функция deep_equal сравнивает две объектные структуры, определяя их структурную идентичность. В примере, показанном на рисунке, deep_equal выполнимо для любой пары из a, b и d. В то же время equal (a, c) истинно, поскольку поля объектов O1 и O4 идентичны, equal (a, d) - ложно. Фактически equal не выполнимо ни для одной пары из d и любого элемента оставшейся тройки. В целом имеют место следующие свойства:

[x]. В результате присваивания x := clone (y) или вызова x.copy (y), выражение equal (x, y) имеет значение true (в случае присваивания это свойство имеет место независимо от того, имеет ли y значение void).

[x]. В результате присваивания x := deep_clone (y), выражение deep_equal (x, y) имеет значение true.

Эти свойства будут отражены в постусловиях соответствующих подпрограмм.

Глубокое хранилище: первый взгляд на сохраняемость

Изучение глубокого копирования и эквивалентности приводит к механизму, обеспечивающему серьезные практические преимущества ОО-метода, естественно, при условии его доступности в среде разработки.

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

Для экземпляров таких классов, как POINT или BOOK1 сохранение и возвращение объектов не является какой-либо новинкой. Эти классы, используемые в качестве первых примеров этой лекции, имеют атрибуты таких типов, как INTEGER, REAL и STRING, для которых доступно хорошо понятное внешнее представление. Сохранение или возвращение экземпляра такого класса из файла подобно выполнению операций ввода-вывода записей в языке Паскаль или структур языка С. Для этих хорошо известных технических проблем существуют стандартные решения. Поэтому резонно ожидать, что объектам в хорошем ОО-окружении можно предоставить процедуры общего назначения, скажем read и write, которые подобно clone и copy будут доступны для всех классов.

Но такие механизмы не могут нас полностью устраивать, поскольку они не управляют главным элементом объектной структуры - ссылками. Так как ссылки могут быть представлены адресами памяти или чем-то подобным, то и для них можно найти подходящее внешнее представление. Это не самая трудная часть проблемы. Сложнее обстоит дело с передачей смысла самих ссылок. Ссылки присоединены к объектам и бесполезны в отсутствие этих объектов. Так что, как только мы начинаем иметь дело с нетривиальными объектами - объектами, содержащими ссылки, нас перестают устраивать старые механизмы сохранения и возвращения, работающие только со значениями. Механизмы должны вместе с объектом обрабатывать и всех его связников (dependents) в соответствии со следующим определением:

Определение: связники, прямые связники

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

Связниками объекта являются сам объект и (рекурсивно) связники его прямых связников.

Для структуры объектов, показанной на рис.8.17, было бы бессмысленно сохранить в файле или передать по сети только объект O1. Операция должна включать связников O1 - объекты O2 и O3.

Рис. 8.17.  Три взаимно зависимых объекта

В этом примере любой из трех объектов рассматривает оставшиеся два как своих связников. В примере, показанном на рис.8.18, объект W1 можно сохранить независимо, но сохранение объектов B1 или B2 требует сохранения также и W1.

Рис. 8.18.  Объекты «Book» и «Writer»

Понятие связников неявно присутствует в представлении deep_equal. Вот общее правило:

Принцип Замыкания Сохраняемости (Persistence Closure principle)

Всякий раз, когда механизм сохранения сохраняет объект, он должен сохранять и связников этого объекта. Всякий раз, когда механизм возвращения возвращает объект, он должен возвращать и связников этого объекта, если они еще не были возвращены.

Базисным механизмом, реализующим эти цели, является библиотечный класс STORABLE, включенный в библиотеку Base. Основными компонентами класса STORABLE являются:

store (f: IO_MEDIUM)
retrieved (f: IO_MEDIUM): STORABLE

Вызов x.store (f) сохраняет в файле, связанном с f, объект, присоединенный к x, вместе со всеми его связниками. Объект, присоединенный к x, называют головным объектом хранимой структуры. Порождающий класс для x должен быть потомком STORABLE. Это требуется только для класса головного объекта и не распространяется на связников.

Класс IO_MEDIUM это еще один класс библиотеки Base, предназначенный для работы не только с файлами, но и для передачи данных по сети. Очевидно, f не должно быть void, а присоединенный файл или сетевое устройство должны допускать запись.

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

Механизм STORABLE это наш первый пример важного свойства сохраняемости (persistence) объектов. Объект сохраняем, если он продолжает существовать по окончании очередной сессии работы системы. Класс STORABLE обеспечивает только частичное решение проблемы, накладывая ряд ограничений:

[x]. В сохраняемой и возвращаемой структуре только один объект известен индивидуально - головной объект. Было бы желательно уметь идентифицировать и другие объекты.

[x]. Как следствие, механизм не позволяет выборочное получение объектов, через запросы или по ключу, как это делается, например, в базах данных.

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

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

Отмеченные выше ограничения механизма STORABLE нисколько не умаляют его практическую ценность. Хорошо известно, что отсутствие подобного механизма - одно из главных препятствий на пути широкого использования сложных структур данных в традиционном окружении. Без него хранение данных требует значительных программистских усилий: для каждого вида структуры приходится писать несколько взаимосвязанных рекурсивных процедур, реализующих операции ввода-вывода, также как и специальные механизмы обхода динамических структур данных. Но хуже всего - при изменении структуры данных приходится вновь обращаться к этим программам, внося соответствующие исправления.

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

Типичным приложением механизма STORABLE является свойство SAVE. Рассмотрим интерактивную систему, например текстовый редактор, графический редактор или систему компьютерного проектирования. Во всех случаях пользователю необходимо предоставить команду SAVE, сохраняющую состояние текущей сессии в файле. Хранимая информация должна быть достаточной для продолжения работы, так что она должна включать все важные структуры данных системы. Механизм STORABLE и хороший выбор головного объекта позволяет реализовать свойство SAVE одной командой:

head.store (save_file)

Уже одной этой причины достаточно для рекомендации выбора ОО-окружения в сравнении с другими более традиционными средами разработки.

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