Книга: Основы объектно-ориентированного программирования
Модульная Композиция
Модульная Композиция
Метод удовлетворяет критерию Модульной Композиции, если он обеспечивает разработку элементов программного продукта, свободно объединяемых между собой для получения новых систем, быть может, в среде, отличающейся от той, для которой эти элементы первоначально разрабатывались.
Композиция определяет процесс, обратный декомпозиции: элементы программного продукта извлекаются из того контекста, для которого они были первоначально предназначены, для использования их вновь в ином контексте.
Рис. 3.3. Композиция
Метод модульного проектирования облегчает этот процесс, создавая автономные элементы программного продукта достаточно независимыми от первоначально поставленной задачи, что делает такое извлечение возможным.
Композиция непосредственно связана с повторным использованием. Этот критерий отражает старую мечту - превратить процесс конструирования программного продукта в работу по складыванию кубиков так, чтобы строить программы из фабрично изготовленных элементов.
[x]. Пример 1: Библиотеки подпрограмм. Библиотеки подпрограмм создаются как наборы компонуемых элементов. Одной из областей, где они успешно используются, являются численные вычисления, основанные на тщательно подготовленных библиотеках подпрограмм для решения задач линейной алгебры, метода конечных элементов, дифференциальных уравнений и др.
[x]. Пример 2: Соглашения, принятые в командном языке Shell операционной системы UNIX. Основные команды системы UNIX оперируют с входным потоком последовательных символов и выдают результат, имеющий такую же стандартную структуру. Потенциальная возможность композиции поддерживается оператором | командного языка "Shell". Запись A | B означает композицию программ. Вначале запускается программа A, ее результаты поступают на вход программы B, начинающей свою работу по завершении работы программы А. Такое системное соглашение благоприятствует композиции программных средств.
[x]. Контрпример: Препроцессоры. Общепринятым способом расширения языка программирования, а иногда и преодоления его недостатков, является использование "препроцессора", принимающего входные данные в расширенном синтаксисе и отображающего их в стандартной для этого языка форме. Типичные препроцессоры для Fortran'а и C поддерживают графические примитивы, расширенные управляющие структуры или операции над базами данных. Однако обычно такие расширения не являются взаимно совместимыми; что не позволяет сочетать два таких препроцессора, и приходится выбирать между, например, графикой или базой данных.
Композиция не зависит от декомпозиции. Фактически эти критерии часто противоречат друг другу. Например, метод нисходящего проектирования, удовлетворяющий, как уже было показано, критерию декомпозиции, обычно приводит к созданию таких модулей, которые нелегко сочетать с модулями, полученными из других источников. При такой декомпозиции модули обычно тесно связаны с теми специфическими требованиями, которые привели к их разработке, и не могут быть приспособлены к использованию в других условиях. Метод нисходящего проектирования не дает рекомендаций по разработке модулей, удовлетворяющих общим требованиям. В нем нет средств такой разработки, он не позволяет ни избежать, ни хотя бы обнаружить программную избыточность модулей, получаемых в различных частях иерархии.
Как композиция, так и декомпозиция являются частью требований к модульному методу проектирования. Неизбежна смесь двух подходов к проектированию: сверху-вниз и снизу-вверх. На этот принцип дополнительности обратил внимание Рене Декарт почти четыре столетия тому назад, как видно из сопоставления двух правил его Рассуждений, приведенных в эпиграфе этой лекции.
Оглавление книги
