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

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

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

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

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

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

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

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

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

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

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