Читать онлайн «Основы объектно-ориентированного программирования». Страница 34

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

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

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

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

[H]

найти_дом

получить_ссуду

подписать_контракт

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

[H1]

найти_дом

ensure

дом_найден

получить_ссуду

ensure

ссуда_получена

подписать_контракт

require

дом_найден and ссуда_получена

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

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

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

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

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

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

Рис. 5.4.  Контекст модуля при разработке сверху вниз

Рисунок, показывающий часть дерева уточнений сверху вниз, иллюстрирует это свойство: C2 пишется, чтобы удовлетворить некоторой части требований C. Характеристики C2 полностью определяются его непосредственным контекстом, т.е. нуждами C. Например, C может быть модулем, отвечающим за анализ некоторых входных данных, а C2 может быть модулем, отвечающим за анализ одной строки (части всего длинного входа).

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

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

Это обсуждение показывает, что проектирование сверху вниз является побочным продуктом того, что можно назвать культом проекта в разработке ПО, считающего, что единицей рассмотрения должен служить индивидуальный проект, никак не связанный с предыдущими или последующими проектами. Реальность не столь проста: n-ый проект компании обычно является вариацией (n-1)-го проекта и предшественником (n+1)-го. Сфокусировавшись лишь на одном проекте, разработка сверху вниз пренебрегает этой особенностью практического создания ПО.

Одна из причин первоначальной привлекательности идей проектирования сверху вниз заключается в том, что этот стиль может быть удобен для объяснения каждого шага разработки. Но то, что хорошо для документации существующей разработки, не обязательно является наилучшим способом для ее проведения. Эта точка зрения была ярко представлена Майклом Джексоном в "Разработке систем" ([Jackson 1983], стр. 370-371):

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

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