Основы объектно-ориентированного программирования
Шрифт:
[x]. (C1) Если в r выполняется инструкция, не являющаяся вызовом подпрограммы (например, присваивание), то текущим остается прежний объект.
[x]. (C2) Неквалифицированный вызов также оставляет тот же объект текущим.
[x]. (C3) Запуск квалифицированного вызова x.f ... делает текущим объект, присоединенный к x. Зная объект OBJ, можно идентифицировать x, используя сформулированные ранее правила T1-T4.
В случаях 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. Другими словами, существует цепочка
Теперь можно дать определение замкнутой системы.
Определение: замкнутая система
Система является замкнутой, если и только если множество ее классов содержит все классы, необходимые корневому классу.
Специализированная программа, например компилятор, может обработать все классы замкнутой системы, начиная с корневого. Рекурсивное обращение к необходимым классам будет происходить по мере того, как встретится упоминание о них. В результате будет сформирован исполняемый код, соответствующий системе в целом.
Этот процесс называется компоновкой или сборкой (assembly) системы и является завершающим этапом разработки.
Программа main отсутствует
Неоднократно подчеркивалось, что системы, разработанные с помощью ОО-подхода, не используют понятия основной программы. Не впускаем ли мы основную программу с черного хода, вводя определение корневого класса и корневой процедуры?
Не совсем. В традиционном понятии основной программы объединены две не связанные концепции:
[x]. Место, с которого начинается выполнение.
[x]. Вершина или фундаментальный компонент архитектуры системы.
Первое условие, безусловно, необходимо. Выполнение любой системы должно начинаться с вполне определенной позиции. В ОО-системах эта позиция определяется корневым классом и корневой процедурой. В случае параллельных, а не последовательных вычислений можно определить несколько начальных точек - по одной для каждой независимой нити или потока (Thread) вычислений.
Концепция вершины уже достаточно обсуждалась ранее и не требует дополнительных комментариев.
Нет никаких оснований для объединения столь разных понятий. Нельзя приписывать особую роль точке начала выполнения кода в архитектуре системы. Типичным примером может служить инициализация операционной системы, выполняемая процедурой загрузки. Этот небольшой и незначительный компонент безусловно нельзя считать центральным в архитектуре операционной системы. Объектная технология исходит из прямо противоположной предпосылки, считая, что важнейшими свойствами системы являются входящий в нее ансамбль классов, функциональные возможности этих классов и их взаимосвязь. В таком контексте выбор корневого класса играет второстепенную роль и при необходимости его можно легко изменить.
Ранее уже указывалось, что необходимо отказаться на раннем этапе разработки системы от вопроса, - "где основная программа?". Если строить архитектуру системы на основе ответа на этот вопрос, то нельзя обеспечить расширяемость и повторное использование кода. Другой подход - готовые к повторному использованию классы, реализации АТД. Программные системы в этом случае представляют собой перестраиваемые ансамбли таких компонент.(О критике функциональной декомпозиции см. "Функциональная декомпозиция", лекция 5)