Дж. Арлоу, А. Нейштадт - UML 2 и Унифицированный процесс - Практический объектно-ориентированный анализ и проектирование, страница 80

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

Один из путей сделать системугибкой и способной изменяться – спроектировать ее так, чтобы обеспечить простое подключение расширений. Интерфейс – ключ к этому.Если есть возможность проектировать системы с использованием интерфейсов, значит, ассоциации и сообщения будут привязаны нек объектам конкретного класса, а к определенному интерфейсу. Этоупрощает добавление в систему новых классов, поскольку интерфейсыопределяют протоколы, которые должны поддерживаться новымиклассами, чтобы из можно было подключить.Подключаемые алгоритмы – хороший пример программных модулей,которые можно подключать по желанию. Некоторое время назад мыработали над системой, которая проводила большое и сложное вычисление над очень большим набором данных. Пользователи хотели экспериментировать с алгоритмом вычисления в попытках найти оптимальную стратегию.

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

Шаблон ФасадШаблон Фасад скрывает сложную реализацию за простым интерфейсом.Сокрытие сложных подсистем за хорошо структурированным простым интерфейсом известно как шаблон Фасад (Faзade). Он задокументирован в [Gamma 1]. Эта книга является ценным источникоммощных многократно используемых шаблонов, которые могут применяться в проектных моделях во многих разных контекстах. Вот чтосказал Гамма (Gamma) о шаблоне Фасад: «Структурирование системыв подсистемы помогает снизить сложность. Общая цель проектирования – свести до минимума общение и зависимости между подсистемами. Один из способов достижения этой цели – введение фасадного объекта, предоставляющего единственный упрощенный интерфейс длянаиболее общих возможностей подсистемы».19.12.

Проектирование с использованием интерфейсов439Шаблон Фасад обеспечивает возможность сокрытия информации и разделения задач – сложные детали внутренней работы подсистемы можно спрятать за простым интерфейсом. Это упрощает систему и позволяет контролировать и управлять связанностью (coupling) подсистем.Интерфейсы, используемые в качестве фасада, могут применяться длясоздания «швов» в системе. Это делается следующим образом:• выявляются связные части системы;• они упаковываются в «subsystem»;• определяется интерфейс для этой подсистемы.19.12.2. Архитектура и шаблон Разбиение на уровниШаблон Разбиение на уровни организовывает подсистемы в семантически связанные уровни.Коллекция подсистем и интерфейсов уровня проектирования образуетвысокоуровневую архитектуру системы.

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

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

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

Однако в основном системы разделяют на представление, бизнеслогику и сервисные уровни.Как показано на рис. 19.20, также довольно распространено более глубокое разбиение уровня бизнеслогики. В данном случае имеется двауровня – предметная область и сервисы. Уровень предметной области440Глава 19. Интерфейсы и компонентыпредставление«subsystem»GUIOrderManagerпредметнаяобластьCustomerManager«subsystem»Customerбизнес!логика«subsystem»Order«subsystem»ProductAccountManagerсервисы«subsystem»Accounts«subsystem»javax.swingслужебныебиблиотекиProductManager«subsystem»java.sql«subsystem»{global}java.utilРис. 19.20.

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

Также обратите внимание, что пакет java.util, содержащий такие универсальныекомпоненты, как Date, используется повсеместно, поэтому обозначенметкой {global} (глобальный). Эта метка указывает на то, что все открытое содержимое данного пакета является видимым везде. Такимспособом показывается, что было решено не отображать зависимостик этому пакету, поскольку они не дают никакой полезной информации.19.13. Преимущества и недостатки интерфейсов44119.13.

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

Связанность (coupling) на самом деле являетсязлейшим врагом разработчика объектов, поскольку высоковзаимосвязанные системы тяжело понимать, обслуживать и развивать. Соответствующее использование интерфейсов может помочь сократить связанность и разбить модель на связные подсистемы.Гибкость может стать причиной сложности, поэтому будьте осторожны.Однако в использовании интерфейсов есть и недостатки.

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

Для обработки этих подвижныхаспектов необходима гибкость. Но системы можно упростить, ограничившись определенной степенью гибкости для более стабильных частей. В некотором роде это один из секретов хорошего ОО анализаи проектирования: выявление стабильных и нестабильных частей системы и соответствующее их моделирование.Откровенно говоря, правильное моделирование системы важнее, чем еегибкость. Всегда основное внимание необходимо уделять прежде всегоправильному моделированию ключевой бизнессемантики и толькопотом думать о гибкости. Запомните правило KISS – keep interfacessweet and simple (интерфейсы должны быть удобными и простыми)!442Глава 19. Интерфейсы и компоненты19.14.