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

Повторное использование замечательная вещь, но иногда надо решить очень простую задачу, например вывести строку. Интересно, как написать такую "программу". После введения понятия системы можно ответить и на этот животрепещущий вопрос.

Следующий маленький класс содержит процедуру, выводящую строку:

class SIMPLE creation

make

feature

make is

-- Вывод строки.

do

print_line ("Hello Sarah!")

end

end

Процедура print_line с параметром некоторого типа выводит значение соответствующего объекта, в данном случае строки. Другая процедура с именем print делает то же самое, но без перехода на новую строку. Обе процедуры доступны во всех классах и унаследованы от универсального предка GENERAL , обсуждаемого далее. (О классе GENERAL см. "Универсальные классы", лекция 16)

Для получения системы, которая будет выводить данную строку необходимо сделать следующее:

[x].(E1) Поместить текст класса в файл simple. e.

[x].(E2) Запустить компилятор.

[x].(E3) Если файл Ace заранее не создан, то можно запросить автоматическое создание шаблона и в режиме его редактирования заполнить имя корневого класса - SIMPLE , системы - my_first и указать каталог кластера.

[x].(E4) После выхода из редактора компилятор осуществит компоновку системы и создаст исполняемый файл my_first .

[x].(E5) Выполнить my_first . В режиме командной строки необходимо просто ввести my_first . В системах с графическим интерфейсом появится новая пиктограмма с именем my_first и запуск программы производится двойным щелчком на ней.

В результате на консоли появится сообщение:

Hello Sarah!

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

[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