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

Структура и порядок: программист в роли поджигателя

Общую картину процесса построения ПО ОО-методом мы уже знаем. Нам также известно, как восстановить цепочку событий, связанную с выполнением некоторой операции. Рассмотрим операцию:

[A]
x.g (u, v, ...)

присутствующую в тексте подпрограммы r класса C и предположим, что x это атрибут. Как и когда она будет выполняться? Класс C должен быть включен в систему, скомпонованную затем с помощью соответствующего файла Ace. Далее следует запустить выполнение системы, которое начнется с создания экземпляра корневого класса. Корневая процедура создания должна выполнить одну или более операций, которые прямо или косвенно создадут объект C_OBJ - экземпляр класса C, а затем выполнят вызов:

[B]
a.r (...)

где a присоединено к C_OBJ. Далее вызов [A] выполнит g с заданными аргументами, используя в качестве цели объект, присоединенный к полю x объекта C_OBJ.

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

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

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

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

Обсуждение

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

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

Отточим наши критические навыки вначале на чем-либо не столь существенном. Поэтому начнем с синтаксиса. Рассмотрим нотацию, используемую при объявлении компонентов. В отличие от многих языков мы не использовали для подпрограмм ключевых слов 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