Бертран Мейер - Основы объектно-ориентированного программирования

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