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

Предварительное рассмотрение свидетельствует о том, что сами ссылки и их разделение необходимы во многих случаях. Некоторые стандартные структуры данных содержат циклически связанные элементы, которые невозможно реализовать без ссылок. В представлениях списков и деревьев удобно предоставить возможность узлам содержать ссылки на своих соседей или родителей. На рис.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) - возможность ссылаться на объект, косвенно именуя его, как, например, в фразе " прекрасная дочь Агамемнона", обращаясь к прекрасной Елене из Трои.