Книга: Основы объектно-ориентированного программирования
Унифицированный доступ
Унифицированный доступ
На первый взгляд один из аспектов приведенной выше классификации может вызывать беспокойство. Во многих случаях необходимо иметь возможность работать с объектом, например с точкой p1, не заботясь о том, какое внутреннее представление используется для p1 - декартово, полярное или иное. Необходимо ли для этого отличать атрибуты от функций?
Ответ зависит от того, с какой точки зрения рассматривать данную проблему - разработчика, автора данного класса POINT или клиента, создавшего класс, использующий POINT. Для разработчика разница между атрибутами и функциями принципиально важна и имеет смысл. Ему необходимо принимать решения о том, какие компоненты будут реализованы как данные в памяти и какие будут доступны в результате вычислений. Но заставлять клиента осознавать эту разницу, было бы серьезной ошибкой. Клиент должен обращаться к значениям x или ? для точки p1, не заботясь и не имея информации о том, как реализованы соответствующие запросы.
Решение проблемы дает принцип унифицированного доступа (Uniform Access principle), введенный в дискуссии о модульности (лекция 3). Принцип декларирует, что клиент должен иметь возможность доступа к свойствам объекта, используя одинаковую нотацию, вне зависимости от того, как это свойство реализовано - в памяти или как результат вычислений (в пространстве или во времени, в виде атрибута или подпрограммы). Этому важному принципу необходимо следовать при разработке нотации для обращения к компонентам класса. Так выражение, обозначающее значение компонента x объекта p1 будет всегда записываться в виде:
p1.x
вне зависимости от того, осуществляется ли доступ к полю данных объекта или выполняется подпрограмма.
При использовании такой нотации неопределенность может возникать только для запросов без аргументов, которые могут быть реализованы и как функции и как атрибуты. Команда должна быть процедурой, запрос с аргументами должен быть функцией, так как атрибуты не могут иметь аргументов. |
Принцип унифицированного доступа необходим для гарантирования автономности компонентов ПО. Он защищает право создателя класса свободно экспериментировать с различными способами реализации, не создавая помех клиентам. (СМ. "Использование утверждений для документирования: краткая форма класса", лекция 11)
Pascal, C и Ada нарушают этот принцип, предоставляя различную нотацию для вызова функций и для доступа к атрибутам. Это объяснимо для таких не ОО-языков (хотя еще в 1966 г. синтаксис Algol W предшественника Pascal удовлетворял этому принципу). Более новые языки, такие как C++ и Java, также не следуют этому принципу. Отход от этого принципа может служить причиной того, что изменения внесенные во внутренние представления (например переход от полярной системы координат к декартовой или иные) повлекут за собой неработоспособность многих клиентских классов. Это является одной из причин нестабильности программных разработок. |
Принцип унифицированного доступа является источником определенных требований и к подготовке документации. Последовательное применение этого принципа должно гарантировать, например, что в официальной документации не содержится сведений о том, является ли данный запрос без аргументов функцией или атрибутом. Это одно из требований к стандартной методике документирования классов, известной как краткая форма класса.
- Унифицированный Доступ
- Что делать, если при установке принтера появляется сообщение Невозможно завершение операции. Подсистема печати недоступн...
- 9.4. Права доступа к squid
- Глава 29 Доступ к канальному уровню
- 10.5. Транзакции и пути доступа меню
- Настройка доступа пользователей к рабочей книге
- 3.5 Проблемы доступа при использовании нескольких протоколов
- Доступ к существующим рабочим областям для документов
- Есть ли быстрый способ доступа к папкам?
- Как открыть доступ к своей папке другим пользователям?
- Я открыл доступ к папке
- Как сделать так, чтобы папка на одном компьютере в сети была доступна для другого компьютера, даже если первый выключен?