этой лекции (в несколько ином контексте для класса LIST, но непосредственно применимы и здесь).
Это обсуждение в полной степени показывает соответствие между классами и АТД:
*Полностью отложенный класс, такой как TABLE, соответствует АТД.
*Полностью эффективный класс, такой как ARRAY_TABLE, соответствует реализации АТД.
*Частично отложенный класс, такой как SEQUENTIAL_TABLE, соответствует семейству реализаций (или, что эквивалентно, частичной реализации) АТД.
Такой класс как SEQUENTIAL_TABLE, аккумулирующий черты, свойственные нескольким вариантам АТД, можно назвать классом поведения (behavior class). Классы поведения предоставляют важные образцы для конструирования ОО-ПО.
Не вызывайте нас, мы вызовем вас
Класс SEQUENTIAL_TABLE дает представление о том, как ОО-технология, используя понятие класса поведения, отвечает на последний оставшийся открытым в лекции 4 вопрос о "Факторизации общих поведений".
Особенно интересна возможность определения такой эффективной процедуры в классе поведения, которая использует в своей реализации отложенные процедуры. Эта возможность проиллюстрирована выше процедурой has. Она показывает, как можно использовать частично отложенные классы для того, чтобы зафиксировать общее поведение нескольких вариантов. В отложенном классе описывается только то общее, что у всех них имеется, а описание вариаций остается потомкам.
Ряд примеров в последующих лекциях будет базироваться на этом методе, который играет важную роль в применении ОО-методов к построению повторно используемого ПО. Он особенно полезен при создании библиотек для конкретных предметных областей и реально применяется во многих контекстах. Типичным примером, описанным в [M 1994a], является разработка библиотек Lex и Parse, предназначенных для анализа языков. В частности, Parse определяет общую схему разбора, по которой будет обрабатываться любой текст (формат данных для языка программирования и т.п.), структура которого соответствует некоторой грамматике. Классы поведения высокого уровня содержат небольшое число отложенных компонентов, таких как post_action, описывающих семантические действия, которые должны выполняться после разбора некоторой конструкции. Для определения собственной семантической обработки пользователю достаточно реализовать эти компоненты.
Такая схема широко распространена. В частности, бизнес-приложения часто следуют стандартным образцам - обработать полученные за день счета, выполнить соответствующую проверку требований на платежи, ввести новых заказчиков и так далее, - индивидуальные компоненты которых могут варьироваться.
В таких случаях можно предоставить набор классов поведения со смесью эффективных компонент, описывающих известную часть, и отложенных компонент, задающих изменяемые элементы. Как правило, эффективные компоненты будут вызывать в своих телах отложенные. При таком подходе потомки могут создавать реализации, удовлетворяющие их потребностям.
|Не все изменяемые элементы следует откладывать. Если доступна реализация по умолчанию, то ее следует включить в качестве эффективного компонента, который при необходимости можно переопределить на уровне потомка. Это упростит разработку потомков, так как в них нужно будет реализовывать новые версии лишь тех компонент, которые
отличаются от реализаций по умолчанию. Разумеется, такой метод следует применять лишь при наличии подходящей реализации по умолчанию, в противном случае соответствующий компонент следует объявить отложенным (как, например, display в классе FIGURE ). |
Этот метод является частью более общего подхода, который можно окрестить "Не вызывайте нас, мы вызовем вас": не прикладная система вызывает повторно используемые примитивы, а универсальная схема позволяет разработчикам приложений размещать их собственные варианты в стратегических местах.
Эта идея не является абсолютно новой. Древняя и весьма почтенная СУБД IMS фирмы IBM уже использовала нечто в этом роде. Структура управления графических систем (таких как система X для Unix) включает "цикл по событиям", в котором на каждой итерации вызываются специфические функции, поставляемые разработчиками приложений. Этот подход известен как схема обратного вызова ( callback scheme ).
То, что предлагает ОО-метод, благодаря классам поведения, представляет систематическую, обеспечивающую безопасность поддержку этой техники разработки. Эта поддержка включает классы, наследование, проверку типов, отложенные классы и компоненты, а также утверждения, позволяющие разработчику сразу зафиксировать, каким условиям должны всегда удовлетворять изменяемые элементы.
Программы с дырами
Только что обсужденные методы являются центральным вкладом ОО-подхода в повторное использование: они предлагают не замороженные навсегда компоненты (которые можно обнаружить в библиотеках подпрограмм), а гибкие решения, которые предоставляют базисные схемы и могут быть адаптированы к нуждам многих разнообразных приложений.
Одной из центральных тем при обсуждении повторного использования была необходимость соединить эту цель с адаптивностью во избежание дилеммы: переиспользовать или переделывать. Этому в точности соответствует только что описанная схема, для которой можно предложить название "программы с дырами". В отличие от библиотек подпрограмм, в которых все, кроме значений фактических параметров, жестко фиксировано, у программ с дырами, использующих классы, образцом для которых служит модель SEQUENTIAL_TABLE, имеется место для частей, создаваемых пользователем.
Эти наблюдения помогают понять образ "блока Лего", часто используемый при обсуждении повторно использования. В наборе Лего компоненты фиксированы, детская фантазия направлена на составление из них интересной структуры. Тот же подход свойственен и программированию, - истоки его в традиционных библиотеках подпрограмм. Часто при разработке ПО требуется в точности обратное: сохранять структуру, но заменять компоненты. На самом деле, этих компонентов может еще и не быть, на их места помещаются "заглушки" (отложенные компоненты), вместо которых затем нужно вставить эффективные варианты.
|По аналогии с детскими игрушками можно вернуться в детство и представить себе игровую доску с отверстиями разной формы, в которые ребенок должен вставлять соответствующие фигуры. Он должен понять, что квадратный блок подходит для квадратного отверстия, а круглый блок - для круглого отверстия. |
Можно также представлять частично отложенный класс поведения (или набор таких
классов, называемый "библиотекой"), как устройство с несколькими электрическими розетками - отложенными классами - в которые разработчик приложения будет вставлять совместимые с ними устройства. Эту метафору можно продолжить: для устройства важны меры предосторожности - утверждения, выражающие требования к допустимым съемным устройствам, например, спецификация розетки определяет допустимое напряжение, силу тока и другие электрические параметры.
Роль отложенных классов при анализе и глобальном проектировании
Отложенные классы играют также ключевую роль при использовании ОО-метода не только на уровне реализации, но и на самых ранних и верхних уровнях построения системы - анализе и глобальном проектировании. Целью является создание спецификации системы и ее архитектуры, для проекта требуется также абстрактное описание каждого модуля без деталей его реализации.
Обычно даваемая в этом случае рекомендация состоит в использовании отдельных обозначений: некоторого "метода" анализа (за этим термином во многих случаях стоит просто некоторая графическая нотация) и некоторого ЯПП (PDL) (языка проектирования программ, зачастую тоже графического). Но у этого подхода много недостатков:
*Разрыв между последовательными шагами процесса разработки представляет серьезную угрозу для качества ПО. Необходимость трансляции из одного формализма в другой может привести к ошибкам и подвергает опасности целостность системы. ОО-технология, напротив, предлагает перспективу непрерывного процесса разработки ПО.
*Многоярусный подход является особенно губительным для этапов сопровождения и эволюции системы. Крайне сложно гарантировать согласованность проекта и реализации на этих этапах.
*Наконец, большинство существующих подходов к анализу и проектированию не предлагают никакой поддержки формальной спецификации функциональных свойств модулей, не зависящей от их реализации, например в форме утверждений.
Последний комментарий приводит к парадоксу уровней: точная нотация, подобная языку, используемому в этой книге, иногда отклоняется как "низкоуровневая" или "ориентированная на реализацию", поскольку внешне выглядит как язык программирования. На самом же деле, благодаря утверждениям и такому механизму абстракции как отложенные классы, их уровень существенно выше уровня большинства имеющихся подходов к анализу и проектированию. Многим требуется время, чтобы осознать это, поскольку раньше их учили тому, что высокий уровень абстракции означает неопределенность и что абстракция всегда должна быть неточной.
Использование отложенных классов для анализа и проектирования позволяет нам одновременно быть абстрактными и точными, и применять один и тот же язык на протяжении всего процесса разработки. При этом устраняются разрывы в концепциях, переход от описания модуля на высоком уровне к реализациям может происходить плавно внутри одного формализма. Даже нереализованные операции проектируемых модулей, представленные отложенными процедурами, можно достаточно точно охарактеризовать с помощью предусловий, постусловий и инвариантов.
Система обозначений, которая к этому моменту развернута почти до конца, покрывает этапы анализа и проектирования, а также и реализации. Одни и те же понятия и конструкции применяются на всех стадиях, различаются только уровни абстракции и детализации.