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

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

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

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

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