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

Собираем все вместе

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

Общая относительность

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

p1.translate (u, v)

Однако возникает следующий вопрос: что в действительности обозначает p1? Ответ опять относителен. Предположим, приведенный вызов присутствует в тексте некоторого класса GRAPHICS, а p1 это атрибут GRAPHICS. Тогда очевидно, что в этом случае p1 фактически означает Current.p1. Но это не ответ на поставленный вопрос, так как неизвестно, что представляет собой объект Current в момент вызова! Другими словами, теперь необходимо установить клиента, вызывающего подпрограмму класса GRAPHICS, в которой используется наш вызов.

Большой Взрыв

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

[x]. (F1) Любой элемент программы может выполняться только как часть вызова подпрограммы.

[x]. (F2) Каждый вызов имеет цель.

Любой вызов может принимать одну из следующих форм:

[x]. неквалифицированная: f (a, b, ...);

[x]. квалифицированная: x.g (u, v, ...) .

Аргументы в обоих случаях могут отсутствовать. Вызов размещен в теле подпрограммы r и может выполняться только как часть вызова r. Предположим, что известна цель этого вызова - некий объект OBJ. Тогда можно легко установить цель этого вызова - t. Возможны четыре варианта, первый из которых относится к неквалифицированному вызову, а остальные - к квалифицированному:

[x]. (T1) Для неквалифицированного вызова t это просто OBJ.

[x]. (T2) Если x это атрибут, то x - поле объекта OBJ-имеет значение, которое, в свою очередь, присоединено к некоторому объекту - он и есть t.

[x]. (T3) Если x - функция, то необходимо сначала осуществить ее вызов (неквалифицированный), результат которого и дает t.

[x]. (T4) Если x - локальная сущность r, то к моменту вызова предыдущие инструкции вычислят значение x, присоединенное к определенному объекту, который и является объектом t.

Проблема в том, что все четыре ответа опять относительны и могут помочь только в том случае, если известно, чем является текущий экземпляр OBJ. Очевидно, что OBJ это цель текущего вызова! Ситуация как в песенке о том, как у попа была собака (в оригинале: котенок съел козленка, котенка укусил щенок, щенка ударила палка ...) - бесконечная цепь.

Для приведения относительных ответов к абсолютным необходимо выяснить, что происходит тогда, когда все только начинается - в момент Большого Взрыва. Итак, определение:

Определение: выполнение системы

Выполнение ОО-программной системы состоит из следующих двух шагов:

[x]. Создание определенного объекта, называемого корневым объектом выполнения.

[x]. Применение определенной процедуры, называемой процедурой создания, к данному объекту.

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

Зная, где все началось, несложно проследить судьбу Current в процессе этой цепной реакции. Первым текущим объектом, созданным в момент Большого Взрыва, является корневой объект. Рассмотрим далее некоторый этап выполнения системы. Пусть r-последняя вызванная подпрограмма, а текущим на момент вызова r был объект OBJ. Тогда во время выполнения r объект Current определяется следующим образом:

[x]. (C1) Если в r выполняется инструкция, не являющаяся вызовом подпрограммы (например, присваивание), то текущим остается прежний объект.

[x]. (C2) Неквалифицированный вызов также оставляет тот же объект текущим.

[x]. (C3) Запуск квалифицированного вызова x.f ... делает текущим объект, присоединенный к x. Зная объект OBJ, можно идентифицировать x, используя сформулированные ранее правила T1-T4. После завершения вызова роль текущего возвращается к объекту OBJ.

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

Итак, нет ничего загадочного и запутанного в определении цели любого вызова, несмотря на всю относительность и рекурсивность правил. Что действительно является удивительным, так это мощь компьютеров, которую мы используем, выступая в роли учеников чародея. Мы создаем относительно небольшой текст заклинания - ПО, и затем выполняем его, в результате чего создаются объекты и выполняются вычисления, и число этих объектов и вычислений столь велико, что кажется почти бесконечным по меркам человеческого сознания.

Системы

Эта лекция акцентирует внимание на классах - элементах конструкции ОО-ПО. Для получения исполняемого кода классы необходимо скомпоновать в систему.

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

[x]. Создать совокупность классов CS, называемую множеством классов (class set) системы.

[x]. Указать класс из CS, являющийся корневым (root class).

[x]. Указать в корневом классе процедуру, играющую роль корневой процедуры создания (root creation procedure) .

Для получения системы эти элементы должны удовлетворять критерию целостности. Каждый класс, прямо или косвенно необходимый корневому, должен быть частью множества CS. Это условие замыкания системы (system closure) .

Понятие необходимости следует уточнить, как это обычно делается при построении замыкания:

[x]. Класс D непосредственно необходим классу C , если текст C ссылается на D. Здесь можно выделить два варианта: C может быть либо клиентом D, либо потомком D.

[x]. Класс Eнеобходим классу C, либо, когда C совпадает с E, либо существует класс D непосредственно необходимый классу С, и классу D необходим (возможно, рекурсивно) класс E. Другими словами, существует цепочка классов, связанных отношением непосредственной необходимости, и началом этой цепочки является класс C, а концом - класс E.

Теперь можно дать определение замкнутой системы.

Определение: замкнутая система

Система является замкнутой, если и только если множество ее классов содержит все классы, необходимые корневому классу.

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

Этот процесс называется компоновкой или сборкой (assembly) системы и является завершающим этапом разработки.

Программа main отсутствует

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

Не совсем. В традиционном понятии основной программы объединены две не связанные концепции:

[x]. Место, с которого начинается выполнение.

[x]. Вершина или фундаментальный компонент архитектуры системы.

Первое условие, безусловно, необходимо. Выполнение любой системы должно начинаться с вполне определенной позиции. В ОО-системах эта позиция определяется корневым классом и корневой процедурой. В случае параллельных, а не последовательных вычислений можно определить несколько начальных точек - по одной для каждой независимой нити или потока (Thread) вычислений.

Концепция вершины уже достаточно обсуждалась ранее и не требует дополнительных комментариев.

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

Ранее уже указывалось, что необходимо отказаться на раннем этапе разработки системы от вопроса, - "где основная программа?". Если строить архитектуру системы на основе ответа на этот вопрос, то нельзя обеспечить расширяемость и повторное использование кода. Другой подход - готовые к повторному использованию классы, реализации АТД. Программные системы в этом случае представляют собой перестраиваемые ансамбли таких компонент.(О критике функциональной декомпозиции см. "Функциональная декомпозиция", лекция 5)

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

Компоновка системы

Как практически реализовать процесс компоновки системы?

Допустим, что операционная система использует обычный способ хранения исходных текстов классов в файлах. Инструментальному средству компоновки (компилятор, интерпретатор) необходима следующая информация:

[x]. (A1) Имя корневого класса.

[x]. (A2) Генеральная совокупность (universe) файлов, содержащих тексты классов, необходимых корневому.

Эта информация не должна содержаться непосредственно в исходных текстах классов. Идентификация класса как корневого в его исходном тексте (А1) нарушает принцип отсутствия основной программы. Включение в исходные тексты классов информации о местонахождении соответствующих файлов означало бы жесткую привязку к файловой системе и, очевидно, является неприемлемым решением. Если размещение изменить, то использование таких классов становится невозможным.

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

Рассмотрим типичный документ Lace, так называемый файл Ace:

system painting root
GRAPHICS ("painting_application")
cluster
base_library: " library base";
graphical_library: " library graphics";
painting_application: " user application"
end -- system painting

Предложение cluster определяет генеральную совокупность файлов, содержащих тексты классов. Оно содержит список кластеров. Кластер - это группа связанных классов, представляющих подсистему или библиотеку. (Модель кластеров обсуждается в лекции 10 курса "Основы объектно-ориентированного проектирования")

Операционные системы, такие как Windows, VMS или Unix, содержат удобный механизм поддержки кластеров - подкаталоги. Их файловые системы имеют древовидную структуру. Конечные узлы дерева (листья), называемые "обычными файлами", содержат непосредственно информацию, а промежуточные узлы, подкаталоги, содержат наборы файлов, состоящие из обычных файлов и подкаталогов.

Рис. 7.7.  Структура каталогов

Можно ассоциировать каждый кластер с подкаталогом. В Lace используется следующее соглашение: каждый кластер, например base_library, имеет связанный с ним подкаталог, имя которого дано в двойных апострофах - " library base". Такое соглашение об именах файлов используется в Windows (dir1dir2 ... ) и здесь приведено только ради примера. Соответствующие имена Unix получаются заменой символов обратной косой черты на обычную.

Каталоги, перечисленные в предложении cluster, могут содержать файлы всех типов. Для работы с генеральной совокупностью процессу компоновки системы необходима информация о том, какие из файлов содержат тексты классов. Используем простое соглашение - текст некоторого класса с именем NAME размещается в файле name.e (нижний регистр). В этом случае, генеральная совокупность представляет собой набор файлов с именами вида name.e в каталогах, перечисленных в предложении cluster.

Предложение root Lace служит для задания корневого класса системы. В данном случае корневым является класс GRAPHICS и он находится в кластере painting_application. Если только один класс в генеральной совокупности называется GRAPHICS, то нет необходимости указывать кластер.

Предположим, что компилятор начинает создание системы, описанной в приведенном файле Ace. Далее предположим, что ни один из файлов системы еще не откомпилирован. Компилятор находит текст корневого класса GRAPHICS в файле graphics.e кластера painting_application, который размещается в каталоге userapplication. Анализируя текст класса GRAPHICS, компилятор находит имена классов, которые необходимы GRAPHICS и ведет поиск файлов с соответствующими именами в каталогах трех кластеров. Далее этот поиск повторяется до тех пор, пока не будут обнаружены все классы, прямо или косвенно необходимые корневому классу GRAPHICS.

Важнейшей особенностью этого процесса является возможность его автоматизации. Разработчику ПО не нужно составлять списки зависимых модулей, известных как "Make-файлы", или указывать в каждом файле имена файлов, необходимых для его компиляции ("директивы Include" в C и C++). Кроме своей утомительности процесс создания этой информации вручную является потенциальным источником ошибок. Единственное, что самостоятельно не сможет определить ни одна утилита - это имя корневого класса и размещение необходимых классов в файловой системе.

Для дальнейшего упрощения работы программиста хороший компилятор должен уметь создавать шаблоны файлов Ace, предложение cluster которых включает базовые библиотеки (ядро, фундаментальные структуры данных и алгоритмы, графика и т. д.) и указание на текущий каталог. В этом случае разработчику остается только указать имя системы и ее корневого класса без необходимости глубокого знания синтаксиса Lace.

Конечным продуктом процесса компиляции является исполняемый файл, имя которого совпадает с именем системы в файле Ace, в данном примере - painting.

Язык содержит ряд других простых конструкций, поддерживающих управление действиями инструментальных средств компоновки, в частности директив компилятора и уровней контроля утверждений. При дальнейшем изучении ОО-метода некоторые из них будут использованы. Уже отмечалось, что Lace поддерживает понятие логического субкластера и может использоваться для описания комплексных структур, включая подсистемы и многоуровневые библиотеки.

Использование независимого от языка разработки языка описания системы аналогичного Lace позволяют классам оставаться системно независимыми. Классы являются компонентами ПО, аналогичными электронным микросхемам, и система собрана из конкретного набора классов подобно компьютеру, собранному из определенного набора микросхем.

Классическое "Hello"

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

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

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)

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

Оглавление книги