Г л а в а  1

ОФОРМЛЕНИЕ ВАРИАНТА

      Проблемы, возникающие при построении расширяемой программы, весьма многочисленны и разнообразны. Для того чтобы облегчить читателю погружение в эту область, его вниманию сначала предлагается относительно несложная общеизвестная задача — оформление варианта. Данная глава практически целиком посвящена различным способам решения указанной задачи. Рассматриваемые способы будут интересовать нас не столько сами по себе, сколько в качестве удобного материала для первого знакомства с некоторыми понятиями из области расширяемых программ.
      Прежде чем перейти непосредственно к задаче оформления варианта, сделаем несколько вводных замечаний.
      Традиционная операционная среда (операционная система, файловая система, редактор, транслятор, компоновщик и т. д.), в которой создается подавляющее большинство программ, как правило, не содержит каких-либо специализированных средств для обеспечения расширяемости. Из-за этого разработчик вынужден использовать подручные штатные средства этой среды, не предназначенные для подобных целей.
      Диапазон доморощенных приемов, применяемых в данной ситуации, невероятно широк, выбор их в значительной степени определяется индивидуальными симпатиями и антипатиями и далеко не всегда оказывается удачным. Однако испытываемые при этом неудобства чаще всего не привлекают внимания, что объясняется двумя причинами. Во-первых, проблемы расширяемости актуальны прежде всего для больших программ, их доля в общем объеме работ по созданию наиболее массовых программ среднего размера обычно невелика. Во-вторых, у рядового программиста отсутствует опыт работы со специализированными средствами построения расширяемых программ, он искренне убежден в том, что «все так делают», и поэтому не замечает неудобств.
      На самом же деле определенные трудности здесь есть, и проявляются они в программах не только большого, но и среднего размера. Характер таких трудностей мы и проиллюстрируем в этой главе на примере достаточно часто встречающейся задачи оформления вариантных алгоритмических решений.

1.1. Постановка задачи

      Из-за чего в программном фонде могут появляться сосуществующие во времени вариантные алгоритмические фрагменты? К ним могут привести, например, следующие обстоятельства.
      Пусть на некоторой стадии создания программы удалось найти усиление для одного из входящих в нее и ранее уже отлаженных алгоритмов. Запрограммировав новый, более удачный алгоритм, обычно не спешат с окончательным уничтожением заменяемого им фрагмента программы, сознательно допуская на какое-то время сосуществование обоих фрагментов в программном фонде.
      Дело в том, что при обнаружении каких-либо неполадок в новой версии программы проще всего отвести подозрения от нового участка, вернув на прежнее место старый фрагмент. Кроме того, нередко нет полной уверенности в том, что новый алгоритм по всем параметрам превосходит старый, и, следовательно, не исключается возможность отката к прежнему решению. В результате два или даже несколько вариантных алгоритмических фрагментов программы будут сосуществовать до тех пор, пока одному из решений не будет отдано безусловное предпочтение — только тогда его конкуренты окончательно ликвидируются.
      Возможна ситуация, когда вариантные фрагменты присутствуют в программном фонде постоянно. Речь идет, конечно, не о старье, отслужившем свое и лишь по забывчивости не попавшем в свое время в мусорную корзину, а о сознательно сохраняемых, регулярно сменяющих друг друга в выполняемой программе равноправных вариантах. В последнем случае вариантные фрагменты представляют собой элементы алгоритмического базиса, позволяющие строить различные версии программы, отражающие, например, различные модификации модели исследуемого объекта. Такое построение программы будет систематически разбираться в гл. 4, специально посвященной многовариантности. Здесь же рассматривается несколько иная, во многом более простая задача: вариантные фрагменты должны сосуществовать лишь на протяжении относительно короткого технологического цикла развития программы.
      Отметим, что сосуществование вариантных фрагментов в программном фонде вовсе не подразумевает их одновременного присутствия в выполняемой программе. Более того, одновременное присутствие фрагментов обычно нежелательно, а нередко и невозможно. Например, если альтернативой линейному поиску в некоторой таблице выбрано хеширование, то в выполняемой программе может работать либо один, либо другой соответствующий вариантный фрагмент, но не оба вместе. Включение обоих фрагментов не только перегружает программу, но и может привести к серьезным противоречиям, в частности из-за нестыковки описаний структур данных.
      Пересмотр некоторого алгоритмического решения может, вообще говоря, повлечь за собой необходимость изменения нескольких далеко отстоящих друг от друга фрагментов программы. Однако, имея в виду скромные иллюстративные цели данной главы, мы вправе принять здесь упрощающее предположение об односвязности вариантных фрагментов. Другими словами, в пределах данной главы будем считать, что вариантный фрагмент программы представляет собой единую непрерывную группу соседствующих строк исходного текста. (К многосвязным вариантам мы обратимся несколько позже.)
 
      Прежде чем перейти к рассмотрению процессов оформления варианта в различных операционных средах, отметим важный критерий качества таких процессов — безболезненность производимых изменений программного фонда. Поскольку обеспечение безболезненности последующих изменений является центральной проблемой построения расширяемой программы, ей посвящается самостоятельный раздел.