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

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

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

Динамические псевдонимы

Для x и y ссылочного типа при непустом значении y присваивание x := y или соответствующее присоединение в результате вызова приведут к тому, что x и y будут присоединены к одному и тому же объекту.

Рис. 8.23.  Разделение как результат присоединения

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

Присоединение x к тому же объекту, что и y, известно как назначение динамического псевдонима (dynamic aliasing). Псевдоним является динамическим, поскольку существует только во время выполнения.

Наличие динамических псевдонимов оказывает более серьезное влияние на операции присваивания с участием сущностей ссылочного типа, нежели с участием сущностей развернутого типа. В случае x и y развернутого типа INTEGER присваивание x := y просто устанавливает для x значение y и никакого связывания x и y не происходит. После подобного присваивания с участием ссылочных типов x и y становятся псевдонимами одного объекта.

Семантика использования псевдонимов

Неприятным последствием применения псевдонимов (и статических, и динамических) является воздействие операций на сущности, даже не упоминаемые в операциях.

Модель вычислений без псевдонимов обладает приятным свойством: приведенный ниже фрагмент всегда справедлив

[БЕЗ СЮРПРИЗОВ]
-- Предположим, что свойство P(y) выполняется
x := y
C (x)
-- P(y) останется выполнимым.

Этот пример подразумевает, что P (y) это частное свойство y, а C (x) некая операция с участием x, но не y. В этом случае никакие действия над x не влияют на значение y.

Для сущностей развернутых типов это действительно так. Приведем типичный пример с x и y типа INTEGER:

-- Предположим, что здесь y = 0
x := y
x := -1
-- По-прежнему y "= 0.

В этом случае нет никакого способа изменить y путем присваивания значения x. Обратимся теперь к аналогичной ситуации с участием динамических псевдонимов. Пусть x и y экземпляры следующего класса C:

class C feature
boolattr: BOOLEAN
-- Булев атрибут для описания некоторого свойства объекта.
set_true is
-- Установка boolattr в true.
do
boolattr := True
end
... Другие компоненты ...
end

Теперь предположим, что тип y это C, и что y в определенный момент времени выполнения не является пустой ссылкой. Тогда следующий пример уже не обладает свойством "БЕЗ СЮРПРИЗОВ":

[СЮРПРИЗ, СЮРПРИЗ!]
-- Предполагаем, что y.boolattr равно false.
x := y
-- Значение y.boolattr по-прежнему false.
x.set_true
-- Но теперь y.boolattr равно true!

Последняя инструкция данного фрагмента никоим образом не содержит y, однако одним из ее результатов является изменение свойств y.

Выработка соглашений для динамических псевдонимов

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

Ответ - частично теоретический и частично практический:

[x]. Операции присваивания необходимы для использования всех преимуществ мощи ОО-метода, в частности для описания сложных структур данных. Необходимо постоянно помнить, что рассматриваемый подход предназначен для решения задач моделирования.

[x]. В практике разработки ОО-ПО для устранения опасностей, связанных с манипулированием ссылками, можно использовать инкапсуляцию.

Поочередно рассмотрим оба указанных аспекта.

Псевдонимы в ПО и за его пределами

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

Рис. 8.24.  Связный циклический список

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

class BOOK3 feature
... Остальные компоненты ...
author: WRITER
end

Здесь необходимость разделения ссылок обусловлена тем, что две книги или более могут быть написаны одним и тем же автором. Во многих примерах данной лекции подразумевается разделение, - так в случае PERSON у нескольких персон может быть один лендлорд. Это вопрос потребностей моделирования, а не реализации.

Если b1 и b2 два экземпляра BOOK3 одного автора, то b1.author и b2.author - псевдонимы, то есть ссылки, присоединенные к одному объекту, и использование любой из них в качестве цели вызова даст в точности одинаковый эффект. Рассмотренные в таком свете динамические псевдонимы выглядят скорее не как потенциально опасная возможность программирования, а как факт из реальной жизни. Это цена, которую необходимо заплатить за возможности использования нескольких имен при обращении к одному объекту.

Можно легко найти нарушения приведенного выше свойства "БЕЗ СЮРПРИЗОВ", не обращаясь к области ПО. Пусть для некоторой книги b определены следующие свойства и операции:

[x]. NOT_NOBEL (b) обозначает: "автор никогда не получал Нобелевскую премию".

[x]. NOBELIZE (b) обозначает: "Присудить Нобелевскую премию автору книги b".

Теперь предположим, что rb обозначает книгу "Красное и черное", а cp - "Пармская обитель". Последующие действия вполне корректны:

[СЮРПРИЗ В ОСЛО]
-- Предположим, что сейчас выполняется NOT_NOBEL(rb)
NOBELIZE(cp)
-- Теперь свойство NOT_NOBEL(rb) уже несправедливо!

Операция над cp изменяет свойство другой сущности rb, которая не упоминается в инструкции! Последствия могут быть весьма значительными (редкая книга Нобелевского лауреата будет переиздана, ее цена возрастет и т.д.). В данной ситуации, не связанной с ПО, произошло в точности то же, что и в предыдущем программном примере после операции x.set_true, повлиявшей на состояние y без упоминания y.

Таким образом, динамические псевдонимы вовсе не являются результатом гнусных трюков программистов со ссылками и указателями. Это следствие свойственного человеку стремления давать имена вещам ("объектам" в наиболее общем смысле этого слова), а иногда и несколько имен одному предмету. В классической риторике эти явления известны как полионимия (polyonymy), например, использование имен "Кибела" (Cybele), "Деметра" (Demeter) и "Церера" (Ceres) "для одной и той же богини, и антономазия (antonomasia) - возможность ссылаться на объект, косвенно именуя его, как, например, в фразе "прекрасная дочь Агамемнона", обращаясь к прекрасной Елене из Трои.

Инкапсуляция действий со ссылками

Теперь накоплено достаточно подтверждений того, что любая система моделирования и разработки ПО должна поддерживать понятие ссылки, а, следовательно, и динамические псевдонимы. Как теперь справиться с неприятными последствиями? Невозможность обеспечить свойство "БЕЗ СЮРПРИЗОВ" показывает, что ссылки и псевдонимы подвергают опасности саму возможность систематического рассмотрения ПО. Это означает, что, изучая исходный текст, нельзя надежно и просто сделать какие либо выводы о свойствах ПО времени выполнения.

Для поиска решения необходимо сначала понять, является ли данная проблема специфической для ОО-метода. Знакомство с другими языками программирования, такими как Pascal, C, PL/I, Ada и Lisp убеждает в том, что и там ведутся подобные дискуссии. Все языки располагают средствами динамического размещения объектов и разрешают объектам содержать ссылки на другие объекты. Существенно различаются лишь уровни абстракции: указатели C и PL/I фактически являются машинными адресами, а Pascal и Ada наряжают указатели в более респектабельные одежды, используя правила типизации.

Что тогда нового в ОО-разработке? Ответ связан не с теоретическими возможностями метода (за исключением важных отличий, связанных со сборкой мусора, ОО-структуры времени выполнения идентичны своим аналогам в Pascal и Ada), а в практике разработки ПО. ОО-разработка подразумевает повторное использование. В частности, любой проект, в котором многочисленные прикладные классы выполняют хитрые манипуляции со ссылками, является примером некорректного использования ОО-подхода. Такие операции должны быть включены в библиотечные классы.

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

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

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

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