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

Решение проблемы дает принцип унифицированного доступа (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