Форма объявлений

Обсуждение

В заключение данной лекции имеет смысл рассмотреть обоснования и альтернативы некоторых принятых решений, связанных с разработкой метода и нотации. Аналогичными разделами завершаются все лекции, в которых вводятся новые понятия.

Отточим наши критические навыки вначале на чем-либо не столь существенном. Поэтому начнем с синтаксиса. Рассмотрим нотацию, используемую при объявлении компонентов. В отличие от многих языков мы не использовали для подпрограмм ключевых слов procedure или function. Форма объявления компонента позволяет отличить, будет ли он атрибутом, процедурой или функцией. Любое объявление компонента всегда начинается с его имени:

f...

Тем самым сохраняется возможность дальнейшего определения компонента любого типа. Если далее присутствует список параметров

g (a1: A; b1: B;...)...

то понятно, что g подпрограмма, которая может быть процедурой или функцией. Далее может следовать:

f: T...

g (a1: A; b1: B;...): T...

В первом примере все еще есть выбор - f может быть либо атрибутом, либо функцией без аргументов. Во втором случае неопределенность заканчивается и g может быть только функцией. Для f неопределенность разрешается в зависимости от того, что следует за T. Если ничего, то f это атрибут, как в следующем примере:

my_file: FILE

Но если далее присутствует ключевое слово is, а за ним тело подпрограммы (do или варианты once и external, рассматриваемые позже), как в примере:

f: T is

--...

do... end

то f - функция. Еще один вариант

f: T is some_value

определяет f как атрибут-константу (constant attribute), значение которой равно some_value. (Атрибуты-константы обсуждаются в лекции 18)

Такой синтаксис позволяет легко распознавать различные виды компонентов, подчеркивая в то же время их фундаментальные общности. Само понятие компонента, объединяющее подпрограммы и атрибуты лежит в русле принципа унифицированного доступа. Общность в объявлениях атрибутов основана на тех же принципах.

Атрибуты или функции?

Рассмотрим подробнее следствия принципа унифицированного доступа и объединения атрибутов и подпрограмм под общим заголовком - компоненты. (См."Унифицированный доступ", лекция 3. См. также данную лекцию.)

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

Рассмотрим класс PERSON, содержащий компонент типа INTEGER без параметров. Если автор клиентского класса записывает выражение

Isabelle.age

то единственно важным будет то, что age возвращает целое число - значение возраста экземпляра PERSON, который во время выполнения присоединен к сущности Isabelle. Компонент age может быть как атрибутом, так и функцией, вычисляющей результат, используя значение атрибута birth_date и текущую дату. Автору клиентского класса нет необходимости знать, какое из этих решений выбрал автор PERSON.

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

Различие в точках зрения поставщика и клиента на атрибут представлено на рис. 7.4 и рис. 7.5, использованных для определения понятия компонента. Рис. 7.5 иллюстрирует разницу между подпрограммами и атрибутами - это внутреннее представление с позиций реализации, используемое поставщиком. Рис. 7.4 в качестве первичного критерия использует разницу между командами и запросами - это внешнее представление клиента.

Решение рассматривать атрибуты и функции без параметров как эквивалентные для клиентов имеет два важных следствия, рассматриваемые подробно в последующих лекциях:

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

[x]. Второе следствие связано с наследованием, как основным способом адаптации программных элементов к новым условиям без разрушения существующего ПО. Если некий класс содержит компонент, представляющий собой функцию без аргументов, то вполне допустимо в классах-потомках переопределить его как атрибут. (См. "Предопределение функции в качестве атрибута", лекция 14)

Дата добавления: 2014-01-07