Реализация пакетов

Часто встречается ситуация, когда один пакет определяет интерфейс, который может быть реализован многими другими пакетами, как это показано на рис. 7.4. В данном случае отношение реализации означа­ет, что шлюз базы данных (Database Gateway) определяет интерфейс, а другие классы шлюзов обеспечивают реализацию. На практике это может означать, что пакет шлюза базы данных (Database Gateway) со­держит интерфейсы и абстрактные классы, которые полностью реали­зуются в других пакетах.

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

Допустим, что вы хотите предоставить некоторый пользовательский интерфейс (UI) выключателей (controls) для включения и выключе­ния некоторого объекта. Мы хотим, чтобы он работал с различными устройствами, такими как обогреватели (heaters) или лампы (lights). Выключатели UI должны вызывать методы обогревателя, но мы не хо­тим, чтобы выключатели зависели от обогревателя. Мы можем избе­жать этой зависимости, определяя в пакете выключателей интерфейс

который затем реализуется каждым классом, работающим с этими вы­ключателями, как показано на рис. 7.5. Здесь представлен пример шаблона Separated Interface (Разделенный интерфейс) [19].

Когда применяются диаграммы пакетов

Я считаю, что диаграммы пакетов исключительно удобны в больших по размерам системах для представления картины зависимостей меж­ду основными элементами системы. Такие диаграммы хорошо соот­ветствуют общепринятым программным структурам. Рисование диа­грамм пакетов и зависимостей помогает держать под контролем зави­симости приложения. Диаграммы пакетов представляют группирую­щий механизм времени компиляции. Для представления компоновки объектов во время выполнения применяются диаграммы составных структур (composite structure) (стр. 155).