2.5. Конфигурационные ориентиры

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

 
Рис. 2.2.  Вычленение модулей — составная часть проектирования структуры программы

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

      2.5.1. Объектная ориентация. Считается весьма продуктивным стиль программирования, где разработчик мыслит проектируемую программу прежде всего как совокупность взаимодействующих модулей-объектов. В самом деле, объекты нередко позволяют достаточно точно и наглядно отобразить многие соотношения, существующие в предметной области. Объектной ориентации посвящена обширнейшая литература, на ней основан ряд популярных языков программирования, так что здесь, по-видимому, нет необходимости ни пересказывать какие-либо детали этого подхода, ни доказывать его перспективность.
      В то же время, поскольку объектная ориентация переживает сейчас период небывалого подъема, ей сопутствует определенная эйфория, благодаря которой классам и объектам иногда явно или неявно приписываются некоторые несуществующие достоинства.
      Так, классы и библиотеки классов нередко преподносятся как счастливо найденная универсальная форма представления многократно используемого программного материала. Что и говорить, библиотеки классов применяются сейчас чрезвычайно широко (см. разд. 2.4.3). Однако класс создавался в первую очередь для целей проектирования рациональной структуры разрабатываемой объектно-ориентированной программы, и было бы несколько нереалистичным ожидать, что как раз он-то и окажется наиболее подходящей конструкцией для оформления произвольной независимой единицы программистского знания. И действительно, современный класс не всегда пригоден на роль модуля многократного использования: в последующих главах будет показано, например, что ему в этом качестве сильно недостает статических горизонтальных связей.
      Еще одно несуществующее достоинство объектной ориентации выражается весьма спорной формулой

объектная ориентация =
изменяемость + многократная используемость

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

добротное программирование =
изменяемость + многократная используемость

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

      2.5.2. Однородная ориентация. Наряду с объектной ориентацией существуют и другие важные конфигурационные ориентиры. Так, программа приобретает много полезных свойств, если в ней выделены группы однородных модулей. Еще на примере оформления варианта (см. гл. 1) можно было заметить, что создание третьего и последующих вариантных фрагментов производится существенно легче, чем первоначальное превращение безвариантной программы в программу с двумя вариантами.
      Объясняется это тем, что к моменту появления третьего варианта уже сформирована группа из двух однородных вариантных фрагментов. Тем самым разработаны (явные или неявные) соглашения о связях, способах организации фрагментов, приняты другие сопутствующие программные решения, т. е. подготовлена почва для подключения новых фрагментов. На начальной же стадии оформления варианта такой группы еще нет, и поэтому организация первых двух вариантных фрагментов требует больших усилий.
      Вариантные фрагменты, делегирующие обычно в выполняемую программу только одного своего представителя, — далеко не единственный пример однородных модулей. Нередко в выполняемую программу попадает некоторое подмножество построенной в программном фонде однородной группы или же вся группа целиком. Группа может размещаться компактно, как в случае ветвей оператора выбора, или же может быть довольно широко раскидана по всей программе, как, скажем, конструкции, обеспечивающие вывод отдельных диагностических сообщений. Многочисленные примеры однородных групп не раз встретятся в последующих главах.
      Там, в частности, будет показано, что поддержка однородности — эффективный инструмент обеспечения расширяемости. Однородная группа, как правило, оказывается точкой роста программы. Более того, расширение программы в большинстве случаев может быть сведено к расширению состава имеющихся однородных наборов.
      Однородные модули лежат в основе обеспечения симметричности программных конструкций, т. е. строгого единообразия реализации сходных, родственных функций. Из симметричности программной реализации следует, в частности, симметричность пользовательского интерфейса, существенно облегчающая освоение и эксплуатацию программы.
      Вычленив и соответствующим образом оформив однородную группу, разработчик значительно упрощает себе последующие манипуляции с ее членами: включение, исключение, просмотр и т. д. Не менее важно и то, что выделение однородных групп делает структуру программы более наглядной. Поэтому однородность модулей — один из приоритетных конфигурационных ориентиров модуляризации.

*     *     *

      К конфигурационным ориентирам следует отнести также и общую конфигурацию программного фонда, получаемую как конечный результат модуляризации. Всем известна простейшая из подобных конфигураций — «единичная» программа, где все разработанные модули включаются в одну расчетную версию. Нам уже знакомы две конфигурации, отличные от такой простейшей структуры: программа с вариантами (см. гл. 1) и библиотека модулей (см. разд. 2.2.3, 2.4.3). Следующая глава посвящена еще одной общей конфигурации — пакету программ.