К объектной технологии

Преждевременное упорядочение

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

Напомним две альтернативных структуры для первого уточнения компилятора.

[C1]
"Прочесть программу и породить последовательность лексем"
"Разобрать последовательность лексем и построить абстрактное синтаксическое дерево"
"Снабдить дерево семантической информацией"
"Сгенерировать по полученному дереву код"
[C'1]
from
   "Инициализировать структуры данных"
until
   "Определения всех функций обработаны"
loop
   "Прочесть определение следующей функции"
   "Сгенерировать частичный код"
end
"Заполнить перекрестные ссылки"

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

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

Упорядочивание и ОО-разработка

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

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

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

[H]
         найти_дом
         получить_ссуду
         подписать_контракт

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

[H1]
         найти_дом
            ensure
                  дом_найден
         получить_ссуду
            ensure
                  ссуда_получена
         подписать_контракт 
            require
               дом_найден and ссуда_получена

Нотация будет введена только в "Проектирование по контракту: построение надежного ПО" , но и здесь все должно быть достаточно ясно. Предложение require задает предусловие, логическое свойство, требуемое операцией перед ее выполнением; ensure - задает постусловие, свойство, выполняемое после завершения операции. Тем самым нам удалось описать результат двух операций, и то, что последняя операция требует для своего выполнения достижения результата этих операций.

Почему логическая форма H1, устанавливающая ограничения, лучше, чем временная форма H? Ответ ясен: H1 выражает минимум требований, избегая чрезмерной спецификации, характерной для H. В самом деле, почему не получить ранее ссуду, а потом уже думать о покупке дома, располагая определенными деньгами, это тактика может быть вполне оправдана для покупателя, у которого главная проблема - финансовая. Насколько возможно, следует поддерживать оба возможных порядка действий, соблюдая логические ограничения.

Подход, основанный не на порядке операций, а на логических ограничениях, более уравновешенный. Каждая операция просто устанавливает, что ей необходимо и что она гарантирует, -все это в терминах абстрактных свойств.

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