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

Особый интерес представляют такие классы как 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).

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

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