Бертран Мейер - Основы объектно-ориентированного программирования

Первое правило касается отношения между внешней системой и ПО. Следующие четыре правила касаются общей проблемы - как модули общаются между собой. Для получения хорошей модульной архитектуры необходим управляемый и строгий метод обеспечения межмодульных связей.

Любая прикладная система стремится удовлетворить потребности некоторой проблемной области. Если имеется хорошая модель для описания этой проблемной области, то желательно обеспечить четкое отображение структуры проблемы описываемой моделью на структуру системы. Из этого следует первое правило:

Модульная структура, создаваемая в процессе конструирования ПО, должна оставаться совместимой с модульной структурой, создаваемой в процессе моделирования проблемной области.

Эта рекомендация следует, в частности, из двух критериев модульности:

[x].Непрерывность: отслеживание модульной структуры проблемы в структуре решения облегчит оценку и ограничит последствия изменений.

[x].Декомпозиция: если уже была проделана некоторая работа по анализу модульной структуры проблемной области, то это может явиться хорошей отправной точкой для разбиения программы на модули.

Правило Минимума Интерфейсов ограничивает общее число информационных каналов, связывающих модули системы:

Каждый модуль должен поддерживать связь с возможно меньшим числом других модулей.

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

Рис. 3.7. Виды структур межмодульных связей

В системе, составленной из n модулей, число межмодульных связей должно быть намного ближе к минимальному значению n-1 , как показано на рисунке (A), чем к максимальному n (n - 1)/2 , как показано на рисунке (B).

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

Вариант (A)на последнем рисунке показывает, как добиться минимального числа связей, n-1 , с помощью весьма централизованной структуры: один основной модуль, а все остальные общаются только с ним. Но имеются намного более "демократические" структуры, такие как (C), содержащие почти такое же число связей. В этой схеме каждый модуль непосредственно общается с двумя ближайшими соседями, центральной власти здесь нет. Такой подход к конструированию программы кажется сначала немного неожиданным, поскольку он не согласуется с традиционной моделью нисходящего проектирования. Но он может приводить к надежным, расширяемым решениям. Это именно такой вид структуры, к созданию которой будет стремиться ОО-метод при его разумном применении.

Правило Слабой связности интерфейсов относится к размеру передаваемой информации, а не к числу связей:

Если два модуля общаются между собой, то они должны обмениваться как можно меньшим объемом информации.

Инженер-электрик сказал бы, что каналы связи между модулями должны иметь ограниченную полосу пропускания:

Рис. 3.8. Канал связи между модулями

Требование Слабой связности интерфейсов следует, в частности, из критериев непрерывности и защищенности.

Особо примечательным контрпримеромявляется конструкция из языка Fortran, знакомая некоторым читателям как "общий блок для мусора" ("garbage common block"). Общим блоком в Fortran'е является директива вида:

COMMON /общее_имя/ переменная1 : переменнаяn.

Переменные, перечисленные в блоке, доступны во всех модулях, содержащих директиву COMMON с тем же общим_именем . Нередко встречаются программы на Fortran'е, в которых каждый модуль содержит одну и ту же огромную директиву COMMON с перечислением всех существенных переменных и массивов, так что каждый модуль может непосредственно обращаться к любым данным программы.

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