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

На рис. 7.4 дана рассмотренная выше классификация, представленная в виде дерева:

Рис. 7.4.  Классификация компонентов класса по их роли

Эта классификация является внешней, основанной на том, каким образом данный компонент выглядит для использующего его клиента.

Можно предложить другую, внутреннюю классификацию, использующую в качестве основного критерия способ реализации компонента в классе:

Рис. 7.5.  Классификация компонентов класса по способу реализации

Унифицированный доступ

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

Ответ зависит от того, с какой точки зрения рассматривать данную проблему - разработчика, автора данного класса POINT или клиента, создавшего класс, использующий POINT. Для разработчика разница между атрибутами и функциями принципиально важна и имеет смысл. Ему необходимо принимать решения о том, какие компоненты будут реализованы как данные в памяти и какие будут доступны в результате вычислений. Но заставлять клиента осознавать эту разницу, было бы серьезной ошибкой. Клиент должен обращаться к значениям x или ρ для точки p1, не заботясь и не имея информации о том, как реализованы соответствующие запросы.

Решение проблемы дает принцип унифицированного доступа (Uniform Access principle), введенный в дискуссии о модульности (лекция 3). Принцип декларирует, что клиент должен иметь возможность доступа к свойствам объекта, используя одинаковую нотацию, вне зависимости от того, как это свойство реализовано - в памяти или как результат вычислений (в пространстве или во времени, в виде атрибута или подпрограммы). Этому важному принципу необходимо следовать при разработке нотации для обращения к компонентам класса. Так выражение, обозначающее значение компонента x объекта p1 будет всегда записываться в виде:

p1.x

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

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

Принцип унифицированного доступа необходим для гарантирования автономности компонентов ПО. Он защищает право создателя класса свободно экспериментировать с различными способами реализации, не создавая помех клиентам. (СМ. "Использование утверждений для документирования: краткая форма класса", лекция 11)

Pascal, C и Ada нарушают этот принцип, предоставляя различную нотацию для вызова функций и для доступа к атрибутам. Это объяснимо для таких не ОО-языков (хотя еще в 1966 г. синтаксис Algol W предшественника Pascal удовлетворял этому принципу). Более новые языки, такие как C++ и Java, также не следуют этому принципу. Отход от этого принципа может служить причиной того, что изменения внесенные во внутренние представления (например переход от полярной системы координат к декартовой или иные) повлекут за собой неработоспособность многих клиентских классов. Это является одной из причин нестабильности программных разработок.

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

Класс POINT

Ниже приведена версия исходного текста класса POINT. Фрагменты, начинающиеся с двух тире "--", представляют собой комментарии, продолжающиеся до конца строки. Комментарии содержат пояснения, облегчающие понимание текста, и не влияют на семантику класса.

indexing

description: "Точка на плоскости"

class POINT feature

x, y: REAL

-- Абсцисса и ордината

rho: REAL is

-- Расстояние до начала координат (0, 0)

do

Result := sqrt (x^2 + y^2)

end

theta: REAL is

-- Полярный угол

do

-- Предлагается реализовать в качестве упражнения (упр. У7.3)

end

distance (p: POINT): REAL is

-- Расстояние до точки p

do

Result := sqrt ((x - p.x)^2 + (y- p.y)^2)

end

translate (a, b: REAL) is

-- Перемещение на a по горизонтали, b по вертикали

do

x := x + a

y := y + b

end

scale (factor: REAL) is

-- Изменение расстояния до начала координат в factor раз

do

x := factor * x

y := factor * y

end

rotate (p: POINT; angle: REAL) is

-- Поворот вокруг p на угол angle

do

-- Предлагается реализовать в качестве упражнения (упр. У7.3)

end

end

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

Класс в основном состоит из предложения, перечисляющего различные компоненты, вводимого ключевым словом feature. Кроме того, присутствует предложение indexing дающее общее описание (description), полезное для понимания функциональности класса, но никак не влияющее на семантику исполнения. Позднее будут рассмотрены три дополнительных предложения: inherit - для наследования; creation - при необходимости использования специального конструктора; invariant - для объявления инвариантов класса. Будет рассмотрена также возможность включения в класс двух или более предложений feature.

Основные соглашения

Класс POINT демонстрирует ряд приемов, которые будут использованы в последующих примерах. Необходимо оговорить основные соглашения.

Распознавание вида компонент

Компоненты x и y объявлены как относящиеся к типу REAL без ассоциированного алгоритма, следовательно, они являются атрибутами. Все остальные компоненты содержат конструкции вида

is

do

... Инструкции ...

end

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

rho: REAL is ...

Это определяет их как функции. Две другие подпрограммы, translate и scale, не возвращают результата (объявление не завершается конструкцией: T, где T некоторый тип) и, соответственно, являются процедурами.

Поскольку x и y являются атрибутами, а rho и theta функциями, данный конкретный класс использует для представления точки декартову систему координат.

Тело подпрограммы и комментарии к заголовку

Тело подпрограммы (предложение do) представляет собой последовательность инструкций. Можно разделять последовательные инструкции и объявления точкой с запятой в традициях Algol-Pascal, но это не обязательно. Далее с целью упрощения точка с запятой будет опускаться между элементами на отдельных строках, но всегда будет использоваться как разделитель нескольких инструкций или объявлений в одной строке. (См. "Война вокруг точек с запятой", лекция 8 курса "Основы объектно-ориентированного проектирования")

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

Другое соглашение о нотации касается использования комментария к заголовку подпрограммы. Уже отмечалось, что комментарии начинаются с двух последовательных тире "--". Они могут размещаться в любом месте, где, по мнению автора, дополнительные разъяснения могут принести пользу. Особую роль играет комментарий к заголовку (header comment). В соответствии с общим стилевым правилом он должен помещаться в начале каждой подпрограммы после ключевого слова is с отступом как в примере класса POINT. Комментарий к заголовку должен кратко отражать назначение подпрограммы.