Основы объектно-ориентированного программирования
Шрифт:
Этот феномен - желание добавить непредусмотренные заранее функции к успешным системам - встречается во всех прикладных областях. Программа для ядерной физики, которая вначале просто применяла некоторый алгоритм для выдачи таблицы чисел по пакетному входу, со временем непременно будет расширена. Она должна будет обрабатывать графический вход, выдавать графический выход и сохранять в базе данных полученные результаты. Компилятор, предназначенный только для трансляции корректных исходных текстов в объектные коды, будет через некоторое время существенно расширен, чтобы красиво распечатывать программы, а также служить верификатором синтаксиса, статическим анализатором и даже - программным окружением.
Процесс
Если при анализе и проектировании используется метод декомпозиции, основанный на функции, то структура системы будет вытекать из исходного понимания разработчиками главной функции системы. При этом добавление всякой новой функции, даже если оно кажется заказчику простым, может разрушить всю структуру системы. Поэтому очень важно найти в качестве критерия декомпозиции свойства менее изменчивые, чем главная функция системы.
Обнаружение вершины
Нисходящий метод проектирования предполагает, что каждая система характеризуется на самом абстрактом уровне своей главной функцией. Хотя многие учебные примеры алгоритмических проблем - "Ханойские башни", "Задача о 8 ферзях" и т. п.
– действительно легко задать с помощью их "верхних" функций, более полезно описывать практические системы в терминах предоставляемых ими услуг.
Рассмотрим какую-либо операционную систему. Наиболее разумно представлять ее как систему, предоставляющую такие услуги, как распределение времени процессора, управление памятью, обращение с устройствами ввода-вывода, декодирование и исполнение команд пользователя. Модули хорошо структурированной ОС стремятся сгруппироваться вокруг этих групп функций. Но это не та структура, которую можно получить при нисходящей функциональной декомпозиции. Этот метод заставляет проектировщика отвечать на искусственный вопрос: "что является "верхней" функцией?", а затем использовать последовательные уточнения полученного ответа в качестве основы для структуры системы. При определенных усилиях можно придти к следующему ответу на исходный вопрос
который далее можно уточнять примерно так:
Уточнения могут продолжаться. Однако маловероятно, что после такого начала кому-либо удастся спроектировать разумно структурированную операционную систему.
Вернемся к примеру с компилятором. Оставив в нем самую суть или представив точку зрения старых учебников, можно сказать, что компилятор - это реализация функции типа вход-выход, трансформирующей текст исходной программы на некотором языке программирования
По-видимому, очевидная отправная точка проектирования сверху вниз - взгляд, согласно которому для каждой новой разработки требуется запросить некоторую специальную функцию - является весьма сомнительной:
У реальной системы нет "вершины"!
Функции и эволюция
Главная функция часто не только не является наилучшим критерием для начального определения системы, но она может также в процессе эволюции системы почти сразу оказаться среди изменяемых свойств.
Рассмотрим в качестве примера программу, имеющую две версии: одну "пакетную", которая выполняет во время сессии одно большое непрерывное вычисление, и другую - интерактивную, которая в каждой сессии реализует последовательность транзакций с разбиением взаимодействия пользователя с системой на более мелкие шаги. Большие научные программы очень часто имеют две версии: одну, которая "пусть работает всю ночь, выполняя большую порцию вычислений", и другую, которая "позволяет мне сначала проверить некоторые вещи, посмотреть на результаты, а затем вычислить еще что-нибудь".
Уточнение сверху вниз пакетной версии могло начаться следующим образом.
и т. д. Проектирование интерактивной версии сверху вниз может происходить в следующем стиле.
(и т. д.)
Начавшаяся таким образом разработка приведет к совершенно неверному результату. Подход сверху вниз не способен учесть то обстоятельство, что результирующие программы должны быть ничем иным как двумя версиями одной и той же программной системы, независимо от того, как они проектируются - одновременно или одна выводится из другой.