Явные интерфейсы

Явные интерфейсы

Четвертое правило является еще одним шагом к укреплению тоталитарного режима в обществе модулей: требуется не только, чтобы любые переговоры ограничивались лишь несколькими участниками и были немногословными; необходимо, чтобы такие переговоры были публичными и гласными!

Всякое общение двух модулей A и B между собой должно быть очевидным и отражаться в тексте A и/или B.

За этим правилом стоят критерии:

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

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

[x]. Понятности. Как можно истолковывать действие модуля A, если на его поведение может косвенным образом влиять модуль B?

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

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

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

Поделитесь на страничке

Следующая глава >

Похожие главы из других книг:

4.3. Интерфейсы

Из книги автора

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


5.3. Интерфейсы .

Из книги автора

5.3. Интерфейсы . Интерфейсы являются элементами диаграммы вариантов использования и были рассмотрены в главе 4. Однако при построении диаграммы классов отдельные интерфейсы могут уточняться и в этом случае для их изображения используется специальный графический символ


10.2. Интерфейсы

Из книги автора

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


6.4.3. Явные критерии

Из книги автора

6.4.3. Явные критерии Перед использованием этих расширений, они должны быть загружены явно, с помощью ключа -m или –match. Так, например, если мы собираемся использовать критерии state, то мы должны явно указать это в строке правила: -m state левее используемого критерия. Некоторые из


Интерфейсы и IDL

Из книги автора

Интерфейсы и IDL Определения методов в IDL являются просто аннотированными аналогами С-функций. Определения интерфейсов в IDL требуют расширения по сравнению с С, так как С не имеет встроенной поддержки этого понятия. Определение интерфейса в IDL начинается с ключевого слова


R.5.2.3 Явные преобразования типа

Из книги автора

R.5.2.3 Явные преобразования типа Конструкция имя-простого-типа (§R.7.1.6), за которой следует список-выражений в скобках образует значение указанного типа с учетом списка выражений. Если список выражений содержит более одного значения, тип должен быть классом с конструктором,


Явные объявления приветствуются

Из книги автора

Явные объявления приветствуются Независимо от того, решите вы назначать конкретные типы данных переменным или нет, каждую переменную перед использованием следует объявить. Как серьезный программист, вы можете сделать так, чтобы VBA заставлял вас объявлять переменные.


5.15. Явные и неявные преобразования чисел

Из книги автора

5.15. Явные и неявные преобразования чисел Программисты, только начинающие изучать Ruby, часто удивляются, зачем нужны два метода to_i и to_int (и аналогичные им to_f и to_flt). В общем случае метод с коротким именем применяется для явных преобразований, а метод с длинным именем — для


Явные преобразования типов

Из книги автора

Явные преобразования типов Явное преобразование типа может быть выполнено посредством операции приведения типа. Она имеет следующую синтаксическую форму(<абстрактное-имя-типа>) <операнд><абстрактное-имя-типа> — специфицирует некоторый тип; <операнд> —


10.5.3. Явные объявления конкретизации

Из книги автора

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


16.8.3. Явные объявления конкретизации

Из книги автора

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


Интерфейсы и упаковка

Из книги автора

Интерфейсы и упаковка Herb Sutterr объяснил, что "интерфейс" класса (подразумевая, функциональные возможности, обеспечиваемые классом) включает также внешние функции, связанные с классом. Им также показано, что правила области видимости имен в C++ поддерживают эти изменения


7.3.6 Ограниченные Интерфейсы

Из книги автора

7.3.6 Ограниченные Интерфейсы Класс slist – довольно общего характера. Иногда подобная общность не требуется или даже нежелательна. Ограниченные вды списков, такие как стеки и очереди, даже более обычны, чем сам обобщенный список. Такие структуры данных можно задать, не