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

Рис. 7.3. Представление точки в полярных координатах

Приведенный пример указывает на необходимость рассмотрения компонентов двух видов:

[x].Некоторые компоненты представлены в пространстве и, можно сказать, ассоциируются с некоторой частью информации каждого экземпляра класса. Они называются атрибутами (attributes). Для точки, представленной в декартовых координатах, атрибутами являются x и y , а в полярных координатах в роли атрибутов выступают rho и theta .

[x].Другие компоненты представлены во времени, и для доступа к ним требуется описать некоторые вычисления (алгоритмы), применимые далее ко всем экземплярам данного класса. В дальнейшем они называются подпрограммамиили методами класса ( routines). В декартовом представлении точек - rho и theta это подпрограммы, а x и y выступают в качестве подпрограмм при использования полярных координат.

Вторая категория - подпрограммы - нуждается в дальнейшей дополнительной классификации. Часть подпрограмм возвращает результат, и их называют функциями (functions). В приведенном примере функциями являются x и y в представлении в полярных координатах, в то время как rho и theta - функции в декартовых координатах, все они возврвщают результат типа REAL. Подпрограммы, не возвращающие результат, соответствуют командам в спецификации АТД и называются процедурами (procedures). Например, класс POINT содержит процедуры translate, rotate и scale.

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

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

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

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

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

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

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

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

p1.x

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

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