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

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

Простые поля

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

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

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

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

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

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

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

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

[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.

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

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

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

Писатели

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

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

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

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

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

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

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

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

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

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

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

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