Связь между модулями может осуществляться различными способами. Модули могут вызывать друг друга (если они являются процедурами), совместно использовать структуры данных и так далее. Правило Минимума Интерфейсов ограничивает число таких связей.
Рис. 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 с перечислением всех существенных переменных и массивов, так что каждый модуль может непосредственно обращаться к любым данным программы.
Возникающие здесь затруднения состоят в том, что любой из модулей может неправильно использовать общие данные, а модули тесно связаны между собой; поэтому проблемы реализации непрерывности (распространение изменений) и защищенности (распространение ошибок) являются чрезвычайно трудно разрешимыми. Тем не менее, эта освященная годами техника все еще остается любимой многими программистами, хотя и ведет к длительным ночным отладочным бдениям.
Разработчики, пользующиеся языками с вложенными структурами, испытывают такие же затруднения. При наличии блочной структуры, введенной в языке Algol и поддерживаемой, в более ограниченной форме, в языке Pascal, можно "вкладывать" блоки, содержащиеся внутри пар begin ... end, внутрь других блоков. К тому же каждый блок может вводить свои собственные переменные, которые имеют смысл лишь в синтаксическом контексте (syntactic scope) этого блока. Например:
local -- Начало блока B1
x, y: INTEGER
do
... Команды блока B1 ...
local -- Начало блока B2
z: BOOLEAN
do
... Команды блока B2 ...
end -- Конец блока B2
local -- Начало блока B3
y, z: INTEGER
do
... Команды блока B3 ...
end -- Конец блока B3
... Команды блока B1 (продолжение) ...
end -- Конец блока B1
Переменная x доступна для всех команд в этом фрагменте программы, в то время как области действия двух переменных с именем z (одна типа BOOLEAN, другая типа INTEGER) ограничены блоками B2 и B3 соответственно. Подобно x, переменная y объявлена на уровне блока B1, но ее область действия не включает блока B3, где другая переменная с тем же именем и тем же типом локально имеет приоритет над самой ближней внешней переменной y. В Pascal'е этот вид блочной структуры существует лишь для блоков, связанных с подпрограммами (процедурами и функциями).3.4)
При наличии блочной структуры, эквивалентом "мусорного" общего блока Fortran'а является объявление всех переменных на самом верхнем (глобальном) уровне. В языках на основе языка С таким эквивалентом является объявление всех переменных внешними (external). (О кластерах см. лекции 10 курса "Основы объектно-ориентированного проектирования". Альтернатива вложенности рассматривается в разделе "Архитектурная роль выборочного экспорта (selective exports)".)
Использование блочной структуры является оригинальной идеей, но это может приводить к нарушению правила Слабой связности Интерфейсов. По этой причине мы будем воздерживаться от применения ее в объектно-ориентированной нотации, развиваемой далее в этом курсе. Язык Simula - объектно-ориентированная производная от Algol'а - поддерживает блочную структуру классов. Опыт работы с ним показал, что способность создавать вложенные классы является излишней при наличии некоторых возможностей, обеспечиваемых механизмом наследования. Структура объектно-ориентированного программного обеспечения содержит три уровня: система является набором кластеров; кластер является набором классов; класс является набором компонент (атрибутов (attributes) и методов (routines)). Кластеры скорее организационное средство, чем лингвистическая конструкция, могут быть вложенными, что позволяет руководителю проекта структурировать большую систему на любое необходимое число уровней; но классы, как и компоненты, имеют одноуровневую плоскую (flat) структуру, поскольку вложенность на любом из этих уровней приведет к излишнему усложнению.
Явные интерфейсы
Четвертое правило является еще одним шагом к укреплению тоталитарного режима в обществе модулей: требуется не только, чтобы любые переговоры ограничивались лишь несколькими участниками и были немногословными; необходимо, чтобы такие переговоры были публичными и гласными!
Всякое общение двух модулей A и B между собой должно быть очевидным и отражаться в тексте A и/или B.
За этим правилом стоят критерии:
[x]. Декомпозиции и композиции. Если нужно разложить модуль на несколько подмодулей или компоновать его с другими модулями, то любая внешняя связь должна быть ясно видна.
[x]. Непрерывности. Должно быть очевидно, какие элементы могут быть затронуты возможным изменением.
[x]. Понятности. Как можно истолковывать действие модуля A, если на его поведение может косвенным образом влиять модуль B?
Переменная x доступна для всех команд в этом фрагменте программы, в то время как области действия двух переменных с именем z (одна типа BOOLEAN, другая типа INTEGER) ограничены блоками B2 и B3 соответственно. Подобно x, переменная y объявлена на уровне блока B1, но ее область действия не включает блока B3, где другая переменная с тем же именем и тем же типом локально имеет приоритет над самой ближней внешней переменной y. В Pascal'е этот вид блочной структуры существует лишь для блоков, связанных с подпрограммами (процедурами и функциями).Переменная x доступна для всех команд в этом фрагменте программы, в то время как области действия двух переменных с именем z (одна типа BOOLEAN, другая типа INTEGER) ограничены блоками B2 и B3 соответственно. Подобно x, переменная y объявлена на уровне блока B1, но ее область действия не включает блока B3, где другая переменная с тем же именем и тем же типом локально имеет приоритет над самой ближней внешней переменной y. В Pascal'е этот вид блочной структуры существует лишь для блоков, связанных с подпрограммами (процедурами и функциями). 3.4