Книга: Основы объектно-ориентированного программирования

Пять правил

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

[x]. Прямое отображение (Direct Mapping).

[x]. Минимум интерфейсов (Few Interfaces).

[x]. Слабая связность интерфейсов (Small interfaces - weak coupling).

[x]. Явные интерфейсы (Explicit Interfaces).

[x]. Скрытие информации (инкапсуляция) (Information Hiding).

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

Прямое отображение

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

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

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

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

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

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

Скрытие информации

Правило Скрытия Информации можно сформулировать следующим образом:

Разработчик каждого модуля должен выбрать некоторое подмножество свойств модуля в качестве официальной информации о модуле, доступной авторам клиентских модулей.

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

Конечно, таким описанием может быть весь текст модуля (текст программы, текст проекта): он и обеспечивает правильное представление о модуле, поскольку это и есть модуль! Но правило Скрытия Информации устанавливает, что в общем случае это не обязательно: описание должно включать лишь некоторые из свойств модуля. Остальные свойства должны оставаться не общедоступными, или закрытыми (секретные) (secret). Вместо терминов - общедоступные и закрытые свойства - используются также термины: экспортируемые и частные (скрытые) (private) свойства. Общедоступные свойства модуля известны также как интерфейс (interface) модуля (не следует путать с пользовательским интерфейсом системы программирования).

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

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

Рис. 3.10.  Модуль в условиях скрытия информации

В качестве характерного примера рассмотрим процедуру поиска по ключу атрибутов, хранящихся в таблице, такой как картотека личного состава или таблица идентификаторов компилятора. Эта процедура существенно зависит от способа представления таблицы - последовательный массив или файл, хэш-таблица, двоичное или индексное (B-Tree) дерево и т.д. Скрытие информации означает, что выбранный способ реализации таблицы не влияет на использование такой процедуры. Модули-клиенты не должны страдать от каких-либо изменений в реализации программы.

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

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

Однако эта рекомендация является нечеткой, так как не дано определение спецификации (specification) и реализации (implementation). Действительно, можно поддаться искушению, изменив определение на прямо противоположное, и утверждать, что спецификация состоит из общедоступных свойств модуля, а реализация - из его скрытых свойств! ОО-подход обеспечит намного более точные рекомендации на основе теории абстрактных типов данных.(См. лекцию 6, в частности "Абстрактные типы данных и скрытие информации".)

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

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

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

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

Из этого обсуждения следует, что ключом к скрытию информации являются не решения по организации доступа к исходному тексту модуля в рамках управления проектом или маркетинговой политики, а строгие языковые правила, определяющие, какие права на доступ к модулю следуют из свойств его источника. В следующей лекции показано, что первые шаги в этом направлении реализованы в таких "языках с инкапсуляцией" как Ada и Modula-2. Объектно-ориентированная технология программирования приведет к более полному решению проблемы.^3.5)

Оглавление книги