Простое представление книги - класс 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 отмечают, что программист может испортить объект при наличии общедоступного поля, так как значение такого поля можно изменить путем непосредственного присваивания. Многие авторы языков вводят такую возможность, а затем предупреждают: "не делайте этого". Логичнее определить метод и нотацию, поддерживающие такие ограничения.

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

Содержание раздела