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