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

Разработчики, пользующиеся языками с вложенными структурами, испытывают такие же затруднения. При наличии блочной структуры, введенной в языке 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 ?

Одной из проблем, возникающих при применении правила Явных Интерфейсов, является то, что межмодульная связь может осуществляться не только через вызов процедуры; источником косвенной связи может быть, например, совместное использование данных (data sharing):

Рис. 3.9. Совместное использование данных

Предположим, что модуль A изменяет данные, а модуль B использует тот же элемент данных x . Тогда A и B оказываются фактически связанными через x , хотя между ними может и не быть явной взаимосвязи, например, вызова процедуры.