Объекты

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

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

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

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

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

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

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

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

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

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

Но не стоит переоценивать "реальность" слова "объект". В науке и технике существует

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

*Не все классы соответствуют типам проблемной области. Многие классы, введенные в

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

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

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

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

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

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

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

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

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

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

class POINT feature x, y: REAL

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

end

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

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

|

В данной книге объекты - набор полей - изображаются в виде смежных прямоугольников, содержащих соответствующие значения. Внизу курсивом в скобках дается имя класса (в данном случае - POINT ). Против каждого поля, тоже курсивом - имена соответствующих атрибутов ( x и y ). Иногда сверху указывается имя объекта (здесь P_OBJ), не имеющее двойника в программном тексте, но позволяющее ссылаться на объект при обсуждении.

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

|

Простые поля

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

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

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

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

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

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

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

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

*Для типа 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.

|

Разрешение присваиваний вида b1.page_count := 355 в C++ и Java отражает ограничения, возникающие при попытках внедрения объектной технологии в контекст языка C.