Динамические структуры, структуры объект и программирование с использованием этих объктов

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

• Для типа BOOLEAN два различных экземпляра обозначаются как True и False.
• Экземпляр CHARACTER будет записываться как символ в апострофах: 'A'.
• Экземпляр STRING обозначается как последовательность символов в двойных апострофах: "Это строка".
• Для обозначения экземпляра INTEGER используем обычную десятичную нотацию: 34, -675, +4.
• Для экземпляров 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 приходится дублировать информацию об одном и том же авторе в виде подобъекта. Причины неприемлемости такого решения:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Класс 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. Такая ссылка на себя может быть косвенной. В ситуации на рис.8.7 объект, имеющий значением поля name: "Almaviva", сам является своим лендлордом (прямая циклическая ссылка). Фигаро любит Сюзанну, которая любит Фигаро (косвенная циклическая ссылка).

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

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

class PERSON1 feature

   name: STRING

   loved_one, landlord: PERSON1