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

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

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

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

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

Производство и описание

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

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

Проектирование сверху вниз: общая оценка

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

Декомпозиция, основанная на объектах

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

Доводы в пользу применения объектов будут довольно краткими, так как этот вопрос был уже ранее рассмотрен: многие из аргументов против основанного на функциях проектирования сверху вниз естественно превращаются в свидетельства в пользу основанного на объектах проектирования снизу вверх.

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

Расширяемость