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

Мейер Бертран

Лекция 8. Динамические структуры: объекты

 

 

Объекты

 

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

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

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

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

 

Что такое объект?

Прежде всего, необходимо напомнить смысл термина "объект". Полная ясность была внесена в предыдущей лекции в виде строгого определения (Определение и объективное правило, см. ):

Определение: объект

Объект - это экземпляр некоторого класса

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

Это официальное определение в мире ОО-ПО. Но в повседневном языке термин "объект" имеет гораздо более широкий смысл. Любая программная система связана с определенной внешней системой, которая может содержать "объекты": точки, линии, поверхности и тела в графической системе; сотрудников и их оклады в системе расчета заработной платы и т.д. В таких ситуациях, как правило, реальным объектам соответствуют программные объекты. Примером может служить класс EMPLOYEE в системе расчета зарплаты, экземпляры которого являются компьютерными моделями сотрудников.

Хорошим следствием дуализма слова "объект" является естественность и мощь ОО-метода, применяемого для целей моделирования реальных систем. Это уже отмечалось при рассмотрении принципа Прямого Отображения (direct mapping), который, как отмечалось, является принципиальным требованием модульного проектирования. Неудивительно, что некоторые классы являются моделями внешних типов объектов проблемной области, а экземпляры классов - моделями реальных объектов. (См. "Прямое отображение", )

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

[x]. Не все классы соответствуют типам проблемной области. Многие классы, введенные в интересах проектирования и реализации, не имеют двойников в моделируемой системе. Именно эти классы на практике могут иметь наибольшее значение и именно их труднее всего спроектировать.

[x]. Некоторые концепции проблемной области естественно приводят к классам, хотя в проблемной области не существует реальных объектов, которые можно было бы поставить в соответствие экземплярам этих классов. Примерами могут быть класс STATE, описывающий состояние системы, или класс COMMAND. (См. и курса "Основы объектно-ориентированного проектирования")

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

 

Базовая форма

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

Пусть O - объект. По определению он является экземпляром некоторого класса. Точнее, он является прямым экземпляром (direct instance) только одного класса, например C.

С учетом наследования O будет тогда косвенным экземпляром других классов, - предков C . Это тема дальнейшего обсуждения; в данной дискуссии достаточно понятия прямого экземпляра. Везде, где не может возникнуть недоразумений, слово "прямой" будет опущено.

Класс C называется порождающим классом (generating class) или просто генератором (generator) объекта O. Заметьте, C- программный текст, а O - структура данных времени выполнения, появляющаяся в результате работы рассмотренных ниже механизмов создания объектов.

Часть компонентов C является атрибутами. Эти атрибуты полностью определяют форму объекта, представляющего собой просто набор полей, по одному на каждый атрибут.

Рассмотрим класс POINT из предшествующей лекции (Текст класса POINT см. в ). Исходный текст имеет вид:

class POINT feature

x, y: REAL

... Объявления подпрограмм ...

end

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

Рис. 8.1.  Экземпляр класса POINT

 

Простые поля

Оба атрибута класса POINT относятся к типу REAL. Следовательно, соответствующие поля прямого экземпляра POINT содержат действительные числа.

Это пример полей, соответствующих атрибутам одного из "базовых" типов. Формально эти типы определены как классы, а их экземпляры принимают значения из предопределенных диапазонов. К базовым (предопределенным, встроенным)типам относятся:

[x]. BOOLEAN, может иметь только два различных экземпляра, соответствующих булевым значениям true и false;

[x]. CHARACTER, экземпляры которого представляют символы;

[x]. INTEGER, экземпляры которого представляют целые числа;

[x]. REAL и DOUBLE, экземпляры которых представляют действительные числа одинарной и двойной точности.

Тип STRING, представляющий конечную последовательность символов, на данном этапе рассматривается как базовый. Далее будет показано, что в действительности он относится к другой категории. ("Строки", см. )

Для каждого базового типа необходимо определить правила записи их значений в исходных текстах. Соглашения просты:

[x]. Для типа BOOLEAN два различных экземпляра обозначаются как True и False.

[x]. Экземпляр CHARACTER будет записываться как символ в апострофах: 'A'.

[x]. Экземпляр STRING обозначается как последовательность символов в двойных апострофах: "Это строка".

[x]. Для обозначения экземпляра INTEGER используем обычную десятичную нотацию: 34, -675, +4.

[x]. Для экземпляров REAL или DOUBLE будет применяться как обычная нотация: 3.5 или -0.05, так и экспоненциальное представление: -5.e-2.

 

Простое представление книги - класс BOOK

Рассмотрим класс с атрибутами базовых типов:

class BOOK1 feature

title: STRING

date, page_count: INTEGER

end

Типичный экземпляр класса выглядит так:

Рис. 8.2.  Объект, представляющий книгу

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

Это означает, что на данном этапе обсуждения объекты подобны записям или структурам в языках Pascal и C. Принципиальное отличие от этих языков выражается в том, что, благодаря наличию механизмов скрытия информации, клиенты классов не могут непосредственно присваивать значения полям таких объектов. В Pascal и в C с незначительными синтаксическими различиями допустимо объявление записи с последующим присваиванием (Внимание: Недопустимая нотация! Только для обсуждения.):

b1: BOOK1

...

b1.page_count := 355

Здесь во время выполнения полю page_count объекта, присоединенного к b1, присваивается значение 355. Для классов такая возможность не допускается. Предоставлять клиентам классов разрешение менять поля объектов было бы насмешкой над правилом скрытия информации. В этом случае терял бы смысл выборочный экспорт, управляемый автором класса. В ОО-подходе модификация значений полей допустима только с помощью процедур класса, добавляемых в том случае, если автор класса решит предоставить такую возможность своим клиентам. Далее такая процедура будет добавлена в класс BOOK1.

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

 

Писатели

Используя указанные выше типы, определим класс WRITER для описания автора книги:

class WRITER feature

name, real_name: STRING

birth_year, death_year: INTEGER

end

Рис. 8.3.  Объект «писатель»

 

Ссылки

Чаще всего нам необходимы объекты с полями, представляющими другие объекты. Например, книга имеет автора, который представлен экземпляром класса WRITER.

Можно ввести понятие подобъекта. В новой версии класса BOOK2 его экземпляры содержат поле, являющееся объектом - экземпляром класса WRITER.

Рис. 8.4.  Два объекта «книга» с подобъектами «писатель»

Такое понятие подобъекта, несомненно, полезно, и далее в этой лекции будет показано, как создавать соответствующие классы.

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

[x]. Расходуется дополнительная память. Можно привести в качестве более характерного примера совокупность объектов, представляющих людей. Каждый объект в качестве подобъекта содержит информацию о стране гражданства. Очевидно, что численность населения намного превышает число стран.

[x]. Более важно, что такая техника не обеспечивает разделения информации. Вполне естественно желание, чтобы внесение изменений в объект WRITER повлекло за собой автоматическое обновление этой информации для всех объектов - книг данного автора.

Лучшим является решение, представленное на . Оно основано на новой версии класса, BOOK3.

Каждый экземпляр BOOK3 в поле author содержит ссылку (reference) на объект типа WRITER. Нетрудно дать точное определение.

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

Ссылка это значение времени выполнения. Она может быть пустой (void) или присоединенной (attached).

Присоединенная ссылка однозначно идентифицирует объект (присоединена к конкретному объекту).

Рис. 8.5.  Два объекта «книга» со ссылками на один и тот же объект «писатель»

На оба поля author экземпляров BOOK3 присоединены к одному экземпляру WRITER. Здесь и далее ссылки, присоединенные к объектам, обозначаются стрелками. На следующем рисунке используется графическое обозначение пустой ссылки, которая может обозначать неизвестного автора.

Рис. 8.6.  Объект, содержащий пустую ссылку (Роман «Кандид» (Candide) опубликован анонимно)

Определение ссылки не подразумевает конкретной аппаратно-программной реализации. Если ссылка не пуста, то она идентифицирует объект и может рассматриваться как абстрактное имя объекта.

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

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

 

Идентичность объектов

Понятие ссылки приводит к концепции идентичности объектов. Каждый объект, созданный в процессе выполнения ОО-системы, уникален и идентифицируется независимо от значений его полей. Возможны две ситуации:

[x]. (I1) Два различных объекта могут иметь абсолютно одинаковые поля.

[x]. (I2) Напротив, поля данного объекта могут изменяться в процессе выполнения системы, но это не влияет на идентификацию объекта.

Эти наблюдения свидетельствуют о неоднозначности высказывания "a обозначает тот же объект, что и b". Можно подразумевать различные объекты с одинаковыми данными (I1) или состояния одного и того же объекта до и после изменения значений полей (I2). Мы будем использовать второе толкование и считать, что значения полей заданного объекта могут изменяться в процессе выполнения, а он остается "тем же самым объектом". В случае (I1) будем говорить о равных (но различных) объектах, точное определение понятия равенства будет дано позже.

Изучение того, как сделать объекты сохранямыми (persistent), заставит нас продолжить изучение свойств идентичности объектов. (См. "Идентичность объектов", курса "Основы объектно-ориентированного проектирования")

 

Объявление ссылок

Класс BOOK1 содержал атрибуты только базовых типов, его вариант BOOK3, содержит атрибут, представляющий ссылку на автора.

class BOOK3 feature

title: STRING

date, page_count: INTEGER

author: WRITER -- Новый атрибут.

end

Объявленный тип дополнительного атрибута author это просто имя соответствующего класса: WRITER. Это будет общим правилом: если имеется стандартное объявление класса

class C feature ... end

то объявление некоторой сущности типа C

x: C

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

 

Ссылка на себя

Ничто не препятствует объекту O1 в определенный момент выполнения системы содержать ссылку, присоединенную к самому O1. Такая ссылка на себя может быть косвенной. В ситуации на объект, имеющий значением поля name: "Almaviva", сам является своим лендлордом (прямая циклическая ссылка). Фигаро любит Сюзанну, которая любит Фигаро (косвенная циклическая ссылка).

Рис. 8.7.  Прямые и косвенные ссылки на себя

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

class PERSON1 feature

name: STRING

loved_one, landlord: PERSON1

end

содержит прямой цикл (PERSON1 - клиент PERSON1).

Обратное утверждение неверно - присутствие цикла в объявлении класса не означает, что циклы обязательно появятся в структурах времени выполнения. Можно объявить класс

class PERSON2 feature

mother, father: PERSON2

end

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

 

Взгляд на структуру объектов периода выполнения

На основе предшествующего рассмотрения выясняется в первом приближении структура ОО-системы в процессе выполнения.

Рис. 8.8.  Возможная структура объектов во время выполнения

Система состоит из нескольких объектов с различными полями. Некоторые поля содержат значения базовых типов, а другие являются пустыми или присоединенными ссылками на другие объекты. Каждый объект является экземпляром некоторого типа, основанного на классе (на рисунке тип указывается под объектом). Некоторые типы представлены единственным экземпляром, но гораздо чаще присутствует несколько экземпляров одного типа. На тип TYPE1 представлен двумя экземплярами, остальные - единственным. Некоторые объекты содержат поля только ссылочного типа (экземпляр TYPE4) или только базовых типов (экземпляр TYPE5). Могут присутствовать прямые или косвенные циклические ссылки (верхнее поле экземпляра TYPE2, по часовой стрелке от нижнего экземпляра TYPE1).

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

Это впечатление не совсем правильно. Впечатление простоты должен создавать программный текст, но не структура объектов периода выполнения. Текст отражает определенные отношения (такие как "любит", "имеет хозяина"). Конкретную структуру объектов периода выполнения можно назвать экземпляром таких отношений, она фиксирует связи между элементами данного набора объектов. Моделируемые отношения могут быть простыми, в то время как отношения индивидуумов конкретного множества объектов - достаточно сложными. Понятие "любит" очень просто, однако любовные отношения конкретных людей могут быть безнадежно запутаны.

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

Сложность динамических структур не должна влиять на статическую картину. Необходимо стараться сохранить набор классов и их отношения настолько простыми, насколько это возможно.

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

 

Объекты как средство моделирования

 

Рассмотренные приемы позволяют продвинуться в понимании возможностей ОО-подхода как средства моделирования. Важно, в частности, прояснить два аспекта: рассмотреть различные миры, связанные с разработкой ПО и отношения между ПО и внешней реальностью.

 

Четыре мира программной разработки

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

[x]. Моделируемую систему, - внешнюю по отношению к программной системе, описываемую типами объектов и их абстрактными отношениями.

[x]. Частную конкретизацию внешней системы, состоящую из объектов с фиксированными отношениями.

[x]. Программную систему, состоящую из классов, связанных ОО-отношениями ("быть клиентом", "быть наследником").

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

Соотношения между этими мирами представлены на .

Рис. 8.9.  Формы и их экземпляры

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

Это различие невыразимо ни в стандартных математических определениях понятия "отношение", ни в программистской терминологии, например в теории реляционных баз данных. Если ограничиться бинарными отношениями, то и в математике и в теории баз данных отношение определяется как множество пар в форме , где x и y являются элементами заданных множеств TX и TY. В терминах программирования все x относятся к типу TX, а все y - к типу TY. Будучи пригодными для математиков, эти определения не подходят для целей моделирования, поскольку не позволяют различать абстрактные отношения и отношения конкретных экземпляров. При моделировании системы отношение "любит" имеет свои общие и абстрактные свойства, совершенно не зависящие от записи того, кто кого любит в конкретной группе людей в некоторый момент времени.

Это обсуждение будет продолжено в лекции 11 , когда будут рассматриваться преобразования между абстрактными и конкретными объектами, и будет дано имя вертикальным стрелкам предыдущего рисунка - функция абстракции. (См. "Функции абстракции", лекция 11 )

 

Реальность: "седьмая вода на киселе"

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

Такое разграничение проводится не всегда. Во многих дискуссиях используется выражение "моделирование реального мира"; аналогичные высказывания содержат и книги по ОО-анализу. Однако говорить о "реальности" применительно к программной системе ошибочно, по крайней мере, по четырем причинам.

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

Во-вторых, понятие реального мира рушится в нередких ситуациях, когда ПО предназначено для разрешения проблем ПО. Рассмотрим компилятор C, написанный на Pascal. Для него "реальными" объектами являются программы на C. Насколько эти программы более реальны, чем сам компилятор? Это наблюдение применимо и к другим системам, работающим с объектами, существующими только в компьютере. (См. )

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

Последний довод наиболее фундаментален. Программная система не является моделью реальности. В лучшем случае это модель модели некоторой части некоторой реальности. Система мониторинга пациента больницы не является моделью больницы, но реализацией конкретной точки зрения на некоторые аспекты работы больницы. Это модель модели некоторой части реальности больницы. Астрономическая программа это не модель вселенной, а всего лишь программная модель чьей-то модели некоторых свойств некоторой части вселенной. Финансовая информационная система не является моделью фондового рынка. Это программная реализация модели, разработанной конкретной компанией для описания тех аспектов фондового рынка, которые соответствуют целям данной компании.

Абстрактные типы данных, лежащие в основе ОО-метода, помогают понять, почему не следует придерживаться широко распространенной, но иллюзорной точкой зрения, что мы имеем дело с "реальным миром". Первый шаг к объектной ориентации, выражаемый теорией АТД, состоит в отказе от реальности ради менее грандиозного, но более аппетитного яства, - представляющего множество абстракций, характеризующих операции, доступные клиентам, и их формальные свойства. (На этом построен девиз модельера АТД - не говорите мне, кто вы, скажите, чем вы обладаете.) Мы никогда не претендуем на то, что рассмотрели все возможные операции и свойства: мы выбрали некоторые из них, подходящие для наших целей и отбросили остальные. Моделирование означает отсекание лишнего.

В идеальном случае программная система приходится соответствующей реальности лишь "седьмой водицей на киселе" (cousin twice removed).

 

Работа с объектами и ссылками

 

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

 

Динамическое создание и повторное связывание

Что не было показано при описании структуры объектов периода выполнения, так это в высшей степени динамичная природа настоящей ОО-модели. Статическая и ориентированная на стеки политика управления объектами характерна для языков уровня Fortran и Pascal соответственно. Противоположной является политика в настоящем ОО-окружении, позволяющая создавать объекты в период выполнения, когда в них возникает потребность. Какому образцу (типу) соответствуют создаваемые объекты, как правило, невозможно предсказать при статической проверке программного текста.

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

Следующий раздел посвящен механизмам, необходимым для создания объектов и манипулирования их полями, в частности, ссылками.

 

Инструкция создания

Рассмотрим создание экземпляра класса BOOK3. Это возможно только с помощью подпрограммы класса, являющегося клиентом BOOK3, как, например:

class QUOTATION feature

source: BOOK3

page: INTEGER

make_book is

-- Создание объекта BOOK3 и присоединение его к source.

do

... См. ниже ...

end

end

Этот класс описывает цитирование книги в других публикациях. Он содержит два поля: ссылку на цитируемую книгу и число страниц, содержащих ссылки на нее.

Механизм создания экземпляра QUOTATION (скоро он будет рассмотрен) предусматривает инициализацию всех его полей. Правило инициализации по умолчанию определяет, что любое ссылочное поле (в данном примере - поле, соответствующее атрибуту source) после инициализации должно содержать пустую ссылку. Другими словами, создание объекта типа QUOTATION не сопровождается созданием объекта типа BOOK3.

Ссылка остается пустой, пока над ней не будут выполнены некоторые действия, - таково общее правило. Изменить значение ссылки можно, создав, например, новый объект. В процедуре make_book это делается следующим образом:

make_book is

-- Создание объекта BOOK3 и присоединение его к source.

do

create source

end

Это иллюстрация простейшей формы инструкции создания: create x , где x - атрибут охватывающего (enclosing) класса или, как будет показано позже, локальная сущность охватывающей подпрограммы. Далее эта базовая нотация будет расширена.

Сущность x, именованная в инструкции (в данном примере source), называется целью (target) инструкции создания.

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

Результат базовой инструкции создания

Эффект инструкции создания вида create x , где тип цели x является ссылочным типом, основанном на классе C, состоит в выполнении трех следующих действий:

[x]. (C1) Создание нового экземпляра C(набора полей, по одному на каждый атрибут C). Пусть OC - это новый экземпляр.

[x]. (C2) Инициализация каждого поля OC соответствующими стандартными значениями по умолчанию.

[x]. (C3) Присоединение значения x (ссылки) к OC.

На этапе C1 создается экземпляр C. На этапе C2 устанавливаются предопределенные значения всех полей, зависящие от типа соответствующего атрибута:

Значения по умолчанию при инициализации

Для ссылок значение по умолчанию - пустая ссылка.

Для полей BOOLEAN значение по умолчанию - False.

Для полей CHARACTER значение по умолчанию - символ null.

Для чисел (типов INTEGER, REAL или DOUBLE) значение по умолчанию - ноль в соответствующем данному типу представлении.

Итак, для цели source типа BOOK3 в соответствии с объявлением класса

class BOOK3 feature

title: STRING

date, page_count: INTEGER

author: WRITER

end

результатом инструкции создания create source, выполняемой при вызове процедуры make_book класса QUOTATION, будет объект изображенный на .

Рис. 8.10.  Созданный и инициализированный объект

После инициализации значения целочисленных полей равны нулю. Ссылочное поле author и поле title типа STRING, содержат пустые ссылки. Тип STRING, о котором ничего не говорится в правилах инициализации, двойственен, - фактически являясь ссылочным типом, он рассматривается во многих ситуациях как базовый тип. (О строках см. )

 

Общая картина

Важно проследить за последовательностью происходящих событий. Для рассмотренного выше экземпляра BOOK3 происходит следующее:

[x]. (B1) Создан экземпляр QUOTATION. Пусть Q_OBJ - этот экземпляр и имеется сущность a, значение которой ссылка, присоединенная к Q_OBJ.

[x]. (B2) Спустя некоторое время после B1 вызов вида a.make_book приводит к выполнению процедуры make_book с Q_OBJ в качестве цели.

Правомерен вопрос - как будет создан сам Q_OBJ (шаг B1)? Это, оставляя проблему, отодвигает ее вглубь. Но к этому моменту мы уже знаем ответ на этот вопрос: все возвращается к первопричине - Большому Взрыву. Для выполнения системы необходимо снабдить ее корневым классом и процедурой этого класса, названной процедурой создания. В начале выполнения автоматически создается один объект - корневой объект - экземпляр корневого класса. Корневой объект является единственным объектом, не создаваемым инструкциями программного текста; он приходит извне, как objectus ex machine (объект от машины). Начав с одного, провидением посланного объекта, далее уже программа может создавать объекты нормальным путем через подпрограммы, выполняющие инструкции создания. Первой выполняемой подпрограммой является процедура создания, автоматически применяемая к корневому объекту. Не всегда, но чаще всего она содержит по крайней мере одну инструкцию создания, что в предыдущей лекции называлось началом грандиозного фейерверка, процесса, создающего столько новых объектов, сколько нужно текущему выполнению.

 

Для чего необходимо явное создание объектов?

Объекты создаются явным образом. Объявление сущности

b: BOOK3

не влечет за собой создание объекта во время выполнения, это происходит, когда некий элемент системы выполнит операцию

create b

Это может показаться удивительным. Разве объявления b недостаточно для создания объекта? Что хорошего в объявлении, если объект не создается?

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

Первый аргумент - reductio ad absurdum (доведение до абсурда). Предположим, что начата обработка объявления и немедленно создается соответствующий объект. Но это экземпляр класса BOOK3, имеющий атрибут author ссылочного типа WRITER, значит поле author - ссылка, для которой опять нужно создавать объект. Этот объект вновь содержит ссылочные поля, требуется опять делать то же самое и начинается длинный путь рекурсивного создания объектов.

Этот аргумент еще более убедителен для таких классов как PERSON1, содержащих ссылки на себя:

class PERSON1 feature

name: STRING

loved_one, landlord: PERSON1

end

Появление каждого экземпляра PERSON1 повлечет за собой создание двух других таких объектов (соответствующих loved_one и landlord ) и начнется бесконечный цикл. Такие прямые или косвенные циклические ссылки не экзотика - они часто встречаются и необходимы.

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

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

[x]. В других случаях, в соответствии с моделью две ссылки должны быть присоединены к одному объекту. (См. ) В примере с циклическими ссылками присутствовали поля loved_one двух персон PERSON1, присоединенные к одному и тому же объекту. Не имело бы смысла создание своего объекта для каждого из этих полей. Все, что требуется, - это операция присваивания (рассмотрена далее в этой лекции) для присоединения ссылки к уже существующему объекту. В еще большей степени это соображение применимо для ссылки на себя (поле landlord верхнего объекта в том же примере).

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

В дискуссии о наследовании будет показано, что инструкция создания может использовать синтаксис create {T}x для создания объекта, чей тип T является наследником типа объявленного для x . (Полиморфное создание, см. лекцию 14 )

 

Процедуры создания

 

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

 

Перекрытие инициализации по умолчанию

Для использования инициализации, отличной от предопределенной умолчанием, необходимо класс снабдить одной или несколькими процедурами создания. Такие процедуры должны быть перечислены в предложении, начинающимся ключевым словом creation в начале класса перед первым предложением feature. Схема такова:

indexing

...

class C creation

p1, p2, ...

feature

... Объявления компонент, включая реализацию процедур p1, p2, ...

end

Совет, отражающий стиль: в случае класса с единственной процедурой создания - для нее рекомендуется имя make . Для классов с двумя и более процедурами создания желателен префикс make_ , за которым следует квалификатор, как в следующем примере POINT . (См. "Правильный выбор имен", лекция 8 курса "Основы объектно-ориентированного проектирования")

Соответствующая инструкция создания в этих случаях имеет другую форму:

create x.p (...)

где p одна из процедур создания перечисленных в разделе creation, и в круглых скобках (...) перечисляются фактические аргументы p. Результатом является создание объекта с использованием значений по умолчанию, как и ранее, а затем вызов p с заданными аргументами. Такая инструкция является комбинацией инструкции создания и вызова процедуры и называется порождающим вызовом (creation call). (Оригинальная версия класса POINT приведена в )

В качестве примера добавим две процедуры создания в класс POINT, что позволит клиентам при создании новой точки указывать ее начальные координаты - декартовы или полярные. Введем процедуры создания: make_cartesian и make_polar. Вот схема:

class POINT1 creation

make_cartesian, make_polar

feature

... Компоненты из предыдущей версии класса:

x, y, ro, theta, translate, scale, ...

feature {NONE} - Этот вариант экспорта рассмотрен ниже.

make_cartesian (a, b: REAL) is

-- Инициализация точки с декартовыми координатами a и b.

do

x := a; y := b

end

make_ polar (r, t: REAL) is

-- Инициализация точки с полярными координатами r и t.

do

x := r * cos (t); y := r * sin (t)

end

end

Для такого класса клиент будет создавать точки инструкциями вида:

create my_point.make_cartesian (0, 1)

create my_point.make_polar (1, Pi/2)

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

Эффект порождающего вызова

Рассмотрим порождающий вызов в форме create x.p(...).

Пусть тип цели x это ссылочный тип, основанный на классе C, p(...) - процедура создания класса C, с заданным списком фактических аргументов. Эффект вызова состоит в выполнении следующих четырех шагов:

[x]. (C1) Создание нового экземпляра C (набора полей, по одному на каждый атрибут C). Пусть OC - это новый экземпляр.

[x]. (C2) Инициализация каждого поля OC соответствующими стандартными значениями по умолчанию.

[x]. (C3) Присоединение значения x (ссылки) к OC.

[x]. (С4) Вызов процедуры p c заданными аргументами и с целевым объектом OC.

 

Статус экспорта процедур создания

Для двух процедур создания, объявленных в классе POINT1, предложение feature имело вид feature {NONE}. Это означает, что эти процедуры закрыты для обычных вызовов, но остаются открытыми для порождающих вызовов. Только что представленные два примера порождающих вызовов являются корректными, но нормальные вызовы, например my_point.make_cartesian (0, 1) или my_point.make_polar (1, Pi/2) некорректны, так как процедуры недоступны клиентам со статусом обычных компонентов.

Решение о закрытости процедур означает, что мы не хотим после создания точки дать возможность клиентам прямого доступа к изменению их координат, хотя они могут делать это через другие процедуры класса, например такие, как translate и scale . Конечно, это лишь одна из возможных политик, вполне разумно экспортировать процедуры создания клиентам, придавая им дополнительно статус обычных процедур.

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

class C creation {A, B, ...}

p1, p2,

...

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

 

Правила, применимые к процедурам создания

Две формы инструкций создания: create x и create x.p (...) , являются взаимно исключающими. Если в классе задано предложение creation , то допускается только порождающие вызовы, базовая форма создания считается в этом случае недопустимой и отвергается компилятором.

Это соглашение кажется на первый взгляд странным, но смысл его становится понятным при рассмотрении требований согласованности объекта. Объект - это не просто набор полей, это реализация АТД, так что поля его будут согласованы только если они удовлетворяют ограничениям, заданным спецификацией АТД. Вот типичный пример. Предположим, что объект задает некоторую личность с двумя полями - год рождения и возраст. Понятно, что согласованность этого объекта не допускает независимых значений этих полей, они связаны вполне определенным соотношением, которое может быть частью спецификации. Инструкция создания обязана всегда производить на свет согласованный объект. Базовая форма этой инструкции применима только в тех частных и довольно редких случаях, когда стратегия умолчания удовлетворяет требованиям согласованности. Во всех остальных случаях в классе требуется определять процедуры создания, что автоматически запрещает использование базовой инструкции создания.

В тех редких случаях, когда инициализация по умолчанию допустима, поскольку удовлетворяет инварианту класса, может появиться желание включить ее в состав процедур создания. Для этого необходимо в список процедур создания включить специальную процедуру, наследуемую от класса ANY, с именем nothing. Как следует из ее имени, эта процедура без аргументов ничего не делает, имея пустое тело. Вот пример подобного включения:

class C creation

nothing, some_creation_procedure, some_other_creation_procedure...

feature

...

Хотя по-прежнему базовая инструкция создания является некорректной в этом случае, но теперь клиент имеет возможность создать объект порождающим вызовом create x.nothing

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

class C creation

-- Здесь ничего не указано!

feature

... Текст класса, как обычно ...

end

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

Если ограничиться ОО-механизмом, рассмотренным до сих пор, то такая возможность запрета на создание объектов класса кажется надуманной. Знакомство с наследованием придает ей смысл, - иногда желательно использовать класс только в интересах наследования. Эта цель и может быть достигнута таким способом. Заметьте, этого же можно добиться, сделав класс абстрактным (отложенным). Но в этом случае у класса должен быть, по крайней мере, один отложенный метод. Иногда разумно полностью определить методы, но не включить в класс процедуры создания.

 

Процедуры создания и перегрузка

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

Как мы видели при обсуждении перегрузки, сигнатура не является подходящим критерием распознавания. Например: конструкторы make_cartesian и make_polar имеют одинаковую сигнатуру, так что придется вводить искусственный аргумент в один из конструкторов, чтобы стало возможным отличить вызов нужного конструктора.

Наша техника кажется предпочтительнее во всех отношениях. Минимум усилий (никаких процедур создания), если инициализация по умолчанию применима; при желании позволяет предотвратить создание объектов клиентами; вводит столько процедур создания, сколько необходимо, не создавая никаких коллизий; каждая процедура создания имеет собственное имя, облегчая понимание ее предназначения, например make_polar .

 

Еще о ссылках

 

Модель периода выполнения определяет важную роль ссылок. Рассмотрим некоторые их свойства, в частности, понятие пустой (void) ссылки и связанные с ней проблемы.

 

Состояния ссылок

Ссылка может находиться в одном из двух состояний - она может быть пустой или присоединенной. Мы уже видели, что изначально ссылка всегда находится в состоянии void и может стать присоединенной благодаря созданию объекта. Вот как выглядит более полная картина, показывающая все возможности перехода между состояниями:

Рис. 8.11.  Возможные состояния ссылки и переходы

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

[x]. "Объект" - это понятие периода выполнения; любой объект является экземпляром класса, создается во время выполнения системы и представляет собой набор полей.

[x]. "Ссылка" - это понятие периода выполнения. Значение ссылки либо void , либо она присоединена к объекту. Точное определение "присоединения" уже появлялось. Присоединенная ссылка однозначно идентифицирует объект.

[x]. "Сущность" - это статическое понятие, применимое к программному тексту, - это идентификатор в тексте класса, представляющий значение или множество значений в период выполнения. Сущностями являются обычные переменные, именованные константы, аргументы подпрограмм и результаты функций.

Если b - сущность ссылочного типа, то ее значением в период выполнения является ссылка, которая может быть присоединена к объекту O. В этом случае говорим, что сущность b присоединена к O.

 

Вызовы и пустые ссылки

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

some_entity.some_feature (arg1, ...)

Для корректного выполнения вызова сущность some_entity должна быть присоединена к нужному целевому объекту. Если случится, что some_entity ссылочного типа и имеет значение void , то вызов не может быть обработан, так как необходим целевой объект.

ОО-система никогда не должна в момент выполнения вызывать компонент с целевым объектом void . Результатом подобного вызова будет исключение (exception).(Исключения и их обработка будут изучаться в )

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

if "x не void" then

x.f (...)

else

...

end

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

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

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

[x]. Если остаются малейшие сомнения, то поставлять ПО с механизмом обработки исключений.

 

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

 

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

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

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

 

Значение void

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

Void

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

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

if x = Void then ...

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

x := Void

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

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

Присваивание Void ссылке не оказывает никакого влияния на объект, ранее присоединенный к ссылке, - разрывается только связь между ссылкой и объектом. Было бы некорректно рассматривать эту операцию как освобождение памяти, так как другие ссылки могут продолжать быть связанными с объектом (на рисунке x может быть отсоединено от объекта O1 , но другие ссылки могут быть еще присоединены к нему). Об управлении памятью смотри следующую лекцию.

 

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

Ссылочное присваивание приводит к тому, что две или несколько ссылок присоединяются к одному объекту. Иногда необходима другая форма присваивания, в результате которой мы хотим получить не копию ссылки, а копию объекта. Эта цель достигается при вызове функции клонирования 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 есть аргумент, а у функции equal - их два. Для ОО-стиля характерен квалифицируемый вызов в форме: y.twin и x.is_equal (y) . Ответ появится в разделе обсуждения, но это будет еще не скоро, так что попытайтесь догадаться сами.

 

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

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

x.copy (y)

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

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

Требование не пустоты y настолько важно, что должен существовать способ для его формального выражения. Фактически речь идет о более общей проблеме: как программа может задать предусловия на аргументы, передаваемые клиентом при ее вызове. Такие предусловия, являясь частным случаем общего понятия "утверждение" в деталях будут обсуждаться в последующих лекциях. Аналогично, нам хотелось бы уметь выражать в виде постусловия семантическое свойство, отмеченное выше, - результат выполнения clone удовлетворяет equal .

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

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

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

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

b := a

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

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

c := clone (a)

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

Заметьте, при клонировании исчезли ссылки на себя. Ссылка landlord объекта O1 была присоединена к самому объекту O1 . У объекта O4 это поле становится ссылкой на оригинал O1 .

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

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

 

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

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

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

Для простоты в этом разделе будем предполагать, что проблема сводится к чтению и записи файлов. Для этих операций будем использовать термины "возвратить" (retrieval) и "сохранить" (storage), адекватные терминам ввод и вывод (input, output). Изучаемые механизмы должны быть применимыми при использовании других средств коммуникации, например при посылке и получении объектов по сети.

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

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

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

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

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

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

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

В этом примере любой из трех объектов рассматривает оставшиеся два как своих связников. В примере, показанном на , объект 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 воссоздает полную структуру объектов. Это означает невозможность использовать два или более таких вызовов для получения отдельных частей структуры, если только структуры не являются независимыми.

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

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

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

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

head.store (save_file)

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

 

Составные объекты и развернутые типы

 

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

 

Ссылок не достаточно

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

[x]. В предыдущей лекции была поставлена важная цель - построение полностью унифицированной системы типов. В этой схеме базовые типы (BOOLEAN, INTEGER и др.) обрабатываются аналогично типам, введенным разработчиком (POINT, BOOK и др.). Тем не менее, если используется сущность n типа INTEGER, то в большинстве случаев удобнее полагать, что значение n - целое число, а не ссылка на объект содержащий целое число. Это удобнее отчасти по соображениям эффективности. Понятно, что для размещения целочисленных объектов необходимо больше памяти, а на обработку косвенного доступа к ним - дополнительное время. Кроме того, концептуально целое число и ссылка на целое число - совершенно различные понятия. Этот довод важен, если нашей целью является построение точной модели.

[x]. Даже в случае сложных, определенных программистом объектов, может оказаться предпочтительным включение в объект O1 подобъекта O2, а не ссылки на внешний объект O2. Причиной такого подхода могут быть повышение эффективности, точное моделирование или и то, и другое.

 

Развернутые типы

Удовлетворить потребность в составных объектах очень просто. Пусть C- класс, определенный так, как это делалось до сих пор

class C feature

...

end

Класс C может использоваться в качестве типа. Любая сущность типа C является ссылкой. По этой причине C называется ссылочным типом (reference type).

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

x : expanded C

Эта нотация использует новое ключевое слово expanded (развернутый). Нотация expanded C означает, что экземпляры этого типа в точности соответствуют экземплярам C. Единственное отличие от обычного объявления типа состоит в том, что сущности типа C обозначают ссылки, которые могут быть присоединены к экземплярам C, а сущности типа expanded C обозначают непосредственно экземпляры C.

Таким образом, к структуре, определенной в предыдущих разделах, добавлено понятие составного объекта (composite object). Объект O называется составным, если одно или более его полей являются объектами - подобъектами (subobjects) O . Следующий класс является примером описания составных объектов:

class COMPOSITE feature

ref: C

sub: expanded C

end

Класс COMPOSITE имеет два атрибута: ref, обозначающий ссылку, и sub, обозначающий подобъект. Вот как выглядит прямой экземпляр COMPOSITE.

Рис. 8.19.  Составной объект с одним подобъектом

Поле ref является ссылкой, присоединенной к экземпляру C (возможно, пустой ссылкой). Поле sub содержит экземпляр C и не может быть пустым.

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

expanded class E feature

... Далее все аналогично любому другому классу ...

end

Так определенный класс называется развернутым классом. Такое объявление класса никак не отражается на экземплярах класса, они остаются такими же, как если бы класс был объявлен просто class E. Но сущности типа E изменяются - теперь их значения не ссылки, а сами объекты. Как следствие этой новой возможности понятие развернутого типа включает два случая:

Определение: развернутый тип

Тип является развернутым в двух случаях:

Он задан в форме: expanded C

Он задан в форме E, где E - развернутый класс.

Объявление вида

x: expanded E

где E - развернутый класс, не будет ошибкой, поскольку эквивалентно

x: E

Таким образом, имеется два вида типов. Тип, не являющийся развернутым, является ссылочным типом. Эту терминологию можно использовать и для сущностей - ссылочные сущности и развернутые сущности. Аналогично и классы могут быть ссылочными и развернутыми.

 

Роль развернутых типов

Почему нам нужны развернутые типы? Они играют три важные роли:

[x]. улучшают эффективность;

[x]. обеспечивают лучшее моделирование;

[x]. поддерживают базисные типы в унифицированной ОО-системе типов.

Первое применение наиболее очевидно: без развернутых типов каждый раз необходимо использовать ссылки для описания составных объектов. Это означало бы при каждом обращении к подобъекту выполнения операции, называемой "разыменование" (dereferencing), что влекло бы к временным потерям. Помимо этого, есть и потери в памяти, поскольку нужно отводить память не только объектам, но и самим ссылкам.

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

Рассмотрим два объявления атрибутов:

D1. ref: S

D2. exp: expanded S

Объявления появляются в классе C, предполагается также, что S это ссылочный класс. Объявление D1 отражает тот факт, что каждый экземпляр класса C "знает о" существовании некоторого экземпляра S (если только ref не является void). Объявление D2 более требовательное: оно устанавливает тот факт, что каждый экземпляр класса C "содержит" экземпляр S. Даже если не думать о проблемах реализации, следует понимать, что речь идет о двух разных отношениях.

Отношение "содержит", поддерживаемое развернутыми типами, не допускает никакого разделения встроенного объекта, в то время как отношение "знает о" допускает несколько ссылок, присоединенных к объекту.

Вот пример объявления класса:

class WORKSTATION feature

k: expanded KEYBOARD

c: expanded CPU

m: expanded MONITOR

n: NETWORK

...

end

Рабочая станция имеет клавиатуру, ЦПУ, монитор и подключена к сети. Клавиатура, ЦПУ и монитор являются частью данного компьютера и не могут разделяться двумя или несколькими рабочими станциями. Однако несколько рабочих станций подключены к одной и той же сети. Эти особенности проявляются в определении класса, использующем развернутые типы для первых трех атрибутов и ссылочный тип для атрибута "сеть".