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

описывающим единственную реализацию АТД, имеется место для реализаций АТД с различной степенью завершенности.

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

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

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

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

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

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