24.Понятие модуля. Преимущества модульного программирования. Структура модуля.

Понятие модульности

Модульность это свойство системы, которая была разложена на внутренне связных, но слабо связанные между собой модули.

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

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

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

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

Таким образом, программист должен находить баланс между двумя противоположными тенденциями: стремлениям спрятать информацию и необходимостью обеспечения видимости тех или других абстракций в нескольких модулях. Парнас, Клеменс и Вейс, предложили следующее правило: "Особенности системы, которые подлежат изменениям, стоит скрывать в отдельных модулях; в качестве межмодульных можно использовать лишь те элементы, вероятность изменения которых имела. Все структуры данных должны быть обособлены в модуле; доступ к ним будет возможен для всех процедур этого модуля и закрыт для всех других. Доступ к данным из модуля должен осуществляться лишь через процедуры данного модуля". Иначе говоря, стоит стремиться построить модули так, чтобы объединить логично связаны абстракции и минимизировать взаимные связки между модулями.

В разных языках программирования модульность поддерживается по-разному. Например, в С++ модулями являются файлы, которые компилируются отдельно. Для С/с++ традиционным является размещение интерфейсной части модулей в отдельные файлы с расширением .п (так называемые файлы-заглавия). Реализация, то есть текст модуля, сохраняется в файлах с расширением .с (в программах на С++ часто используются расширения .ее, .ср и .срр). Связь между файлами объявляется директивой макропроцессору #include. Такой подход строится исключительно на соглашении и не является строгим требованием самого языка. В языке Object Pascal принцип модульности формализированный немного строже. В этом языке определен особенный синтаксис для интерфейсной части и реализации модуля (unit). Язык Ada идет еще на шаг дальше: модуль (что называется package) также имеет две части - спецификацию и тело. Но, в отличие от Object Pascal, допускается раздельное определение связей с модулями для спецификации и тела пакета. Таким образом, допускается, чтобы тело модуля мало связки с модулями, невидимыми для его спецификации. Со временем при в проектировании программ акцент сместился с организации процедур на организацию структур данных. Помимо всего прочего это вызвано и ростом размеров программ. Модулем обычно называют совокупность связанных процедур и тех данных, которыми они управляют.

Парадигма программирования приобрела вид:

Определите, какие модули нужны; поделите программу так, чтобы данные были скрыты в этих модулях

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

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