Чтение онлайн

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

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

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

Статические псевдонимы закрепляют два имени за одним и тем же программным элементом в исходном тексте, и они всегда обозначают одно и то же значение вне зависимости от событий, происходящих во время выполнения. Этот прием включен в некоторые языки программирования. В Fortran директива EQUIVALENCE означает, что две переменные разделяют содержимое одной и той же области памяти. Директива препроцессора C #define x y определяет, что любое упоминание x в тексте программы эквивалентно y.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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