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

Роль отложенных классов

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

Назад к абстрактным типам данных

Насыщенные утверждениями отложенные классы хорошо подходят для представления АТД. Прекрасный пример - отложенный класс для стеков. Мы уже описывали процедуру put, сейчас приведем возможную версию полного описания этого класса.

indexing
description:
"Стеки (распределительные структуры с дисциплиной Last-in, First-Out), %
%не зависящие от выбора представления"
deferred class
STACK [G]
feature -- Доступ
count: INTEGER is
-- Число элементов.
deferred
end
item: G is
-- Последний вставленный элемент.
require
not_empty: not empty
deferred
end
feature - Отчет о статусе
empty: BOOLEAN is
-- Стек пустой?
do
Result := (count = 0)
end
full: BOOLEAN is
-- Стек заполнен?
deferred
end
feature - Изменение элемента
put (x: G) is
-- Втолкнуть x на вершину.
require
not full
deferred
ensure
not_empty: not empty
pushed_is_top: item = x
one_more: count = old count + 1
end
remove is
-- Вытолкнуть верхний элемент.
require
not empty
deferred
ensure
not_full: not full
one_less: count = old count - 1
end
change_top (x: T) is
-- Заменить верхний элемент на x
require
not_empty: not empty
do
remove; put (x)
ensure
not_empty: not empty
new_top: item = x
same_number_of_items: count = old count
end
wipe_out is
-- Удалить все элементы.
deferred
ensure
no_more_elements: empty
end
invariant
non_negative_count: count >= 0
empty_count: empty = (count = 0)
end

Этот класс показывает, как можно реализовать эффективную процедуру, используя отложенные: например, процедура change_top реализована в виде последовательных вызовов процедур remove и put. (Такая реализация для некоторых представлений, например, для массивов, может оказаться не самой лучшей, но эффективные потомки класса STACK могут ее переопределить.)

Если сравнить класс STACK со спецификацией соответствующего АТД, приведенной в лекции 6, то обнаружится удивительное сходство. Подчеркнем, в частности, соответствие между функциями АТД и компонентами класса, и между пунктом PRECONDITIONS и предусловиями процедур. Аксиомы представлены в постусловиях процедур и в инварианте класса.

Добавление операций change_top, count и wipe_out в данном случае несущественно, так как они легко могут быть включены в спецификацию АТД (см. упражнение У6.8). Отсутствие явного эквивалента функции new из АТД также несущественно, так как созданием объектов будут заниматься процедуры-конструкторы в эффективных потомках этого класса. Остаются три существенных отличия.

Первое из них - это введение функции full, рассчитанной на реализации с ограниченным числом элементов стека, например, на реализацию массивами. Это типичный пример ограничения, которое несущественно на уровне спецификации, но необходимо для разработки практических систем. Отметим однако, что это отличие между АТД и отложенным классом можно легко устранить, включив в спецификацию АТД средства для охвата ограниченных стеков. При этом общность не будет потеряна, так как некоторые реализации (например, с помощью списков) могут реализовывать full тривиальными процедурами, всегда возвращающими ложь.

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

Наконец, как тоже уже отмечалось, механизм утверждений недостаточно выразителен для некоторых аксиом АТД. Из четырех аксиом стеков

Для всех x: G, s: STACK [G],

1

item (put (s, x)) = x

2

remove (put (s, x)) = s

3

empty (new)

4

not empty (put (s, x))

все, кроме (2), имеют прямые эквиваленты среди утверждений. (Мы предполагаем, что для (3) процедуры-конструкторы у потомков обеспечат выполнение условия empty). Причины таких ограничений уже были объяснены и были намечены возможные пути их преодоления - языки формальных спецификаций IFL.

Отложенные классы как частичные интерпретации: классы поведения

Не все отложенные классы так близки к АТД как STACK. В промежутке между полностью абстрактным классом, таким как STACK, в котором все существенные компоненты отложены, и эффективным классом, таким как FIXED_STACK, описывающим единственную реализацию АТД, имеется место для реализаций АТД с различной степенью завершенности.

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

Рис. 14.13.  Варианты понятия "таблица"

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

Особый интерес представляют такие классы как SEQUENTIAL_TABLE. Этот класс все еще отложенный, но его статус находится посредине между полностью отложенным статусом как у класса TABLE и полностью эффективным как у ARRAY_TABLE. У него достаточно информации, чтобы позволить себе реализацию некоторых специфических алгоритмов, например, в нем можно полностью реализовать последовательный поиск:

has (x: G): BOOLEAN is
-- x имеется в таблице?
do
from start until after or else equal (item, x) loop
forth
end
Result := not after
end

Эта функция эффективна, хотя ее алгоритм использует отложенные компоненты. Компоненты start (поместить курсор в первую позицию), forth (сдвинуть курсор на одну позицию), item (значение элемента в позиции курсора), after (находится ли курсор за последним элементом?) являются отложенными в классе SEQUENTIAL_TABLE и в каждом из показанных на рисунке потомков этого класса они реализуются по-разному.

Эти реализации были приведены при обсуждении повторного использования. Например класс ARRAY_TABLE может представлять курсор числом i, так что процедура start реализуется как i := 1, а item как t @ i и т.д.

Отметим важность включения предусловия и постусловия компонента forth, а также инварианта объемлющего класса для гарантирования того, что все будущие реализации будут удовлетворять одной и той же базовой спецификации. Эти утверждения приводились ранее в этой лекции (в несколько ином контексте для класса LIST, но непосредственно применимы и здесь).

Это обсуждение в полной степени показывает соответствие между классами и АТД:

[x]. Полностью отложенный класс, такой как TABLE, соответствует АТД.

[x]. Полностью эффективный класс, такой как ARRAY_TABLE, соответствует реализации АТД.

[x]. Частично отложенный класс, такой как SEQUENTIAL_TABLE, соответствует семейству реализаций (или, что эквивалентно, частичной реализации) АТД.

Такой класс как SEQUENTIAL_TABLE, аккумулирующий черты, свойственные нескольким вариантам АТД, можно назвать классом поведения (behavior class). Классы поведения предоставляют важные образцы для конструирования ОО-ПО.

Не вызывайте нас, мы вызовем вас

Класс SEQUENTIAL_TABLE дает представление о том, как ОО-технология, используя понятие класса поведения, отвечает на последний оставшийся открытым в лекции 4 вопрос о "Факторизации общих поведений".

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

Ряд примеров в последующих лекциях будет базироваться на этом методе, который играет важную роль в применении ОО-методов к построению повторно используемого ПО. Он особенно полезен при создании библиотек для конкретных предметных областей и реально применяется во многих контекстах. Типичным примером, описанным в [M 1994a], является разработка библиотек Lex и Parse, предназначенных для анализа языков. В частности, Parse определяет общую схему разбора, по которой будет обрабатываться любой текст (формат данных для языка программирования и т.п.), структура которого соответствует некоторой грамматике. Классы поведения высокого уровня содержат небольшое число отложенных компонентов, таких как post_action, описывающих семантические действия, которые должны выполняться после разбора некоторой конструкции. Для определения собственной семантической обработки пользователю достаточно реализовать эти компоненты.

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

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

Этот метод является частью более общего подхода, который можно окрестить "Не вызывайте нас, мы вызовем вас": не прикладная система вызывает повторно используемые примитивы, а универсальная схема позволяет разработчикам приложений размещать их собственные варианты в стратегических местах.

Эта идея не является абсолютно новой. Древняя и весьма почтенная СУБД IMS фирмы IBM уже использовала нечто в этом роде. Структура управления графических систем (таких как система X для Unix) включает "цикл по событиям", в котором на каждой итерации вызываются специфические функции, поставляемые разработчиками приложений. Этот подход известен как схема обратного вызова (callback scheme).

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

Программы с дырами

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

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

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

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

Роль отложенных классов при анализе и глобальном проектировании

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

Обычно даваемая в этом случае рекомендация состоит в использовании отдельных обозначений: некоторого "метода" анализа (за этим термином во многих случаях стоит просто некоторая графическая нотация) и некоторого ЯПП (PDL) (языка проектирования программ, зачастую тоже графического). Но у этого подхода много недостатков:

[x]. Разрыв между последовательными шагами процесса разработки представляет серьезную угрозу для качества ПО. Необходимость трансляции из одного формализма в другой может привести к ошибкам и подвергает опасности целостность системы. ОО-технология, напротив, предлагает перспективу непрерывного процесса разработки ПО.

[x]. Многоярусный подход является особенно губительным для этапов сопровождения и эволюции системы. Крайне сложно гарантировать согласованность проекта и реализации на этих этапах.

[x]. Наконец, большинство существующих подходов к анализу и проектированию не предлагают никакой поддержки формальной спецификации функциональных свойств модулей, не зависящей от их реализации, например в форме утверждений.

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

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

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

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