Фаулер М. Архитектура корпоративных программных приложений

Подождите немного. Документ загружается.

484 Часть II. Типовые решения

к удаленному источнику, объекты приложения будут обращаться к шлюзу, который пре-

образует простые вызовы методов в вызовы специализированного API.

Принцип действия

Концепция типового решения шлюз очень проста. Возьмем внешний источник дан-

ных. Какие действия должно совершать приложение по отношению к этому источнику?

Создайте простой API, наполните его всеми необходимыми методами и воспользуйтесь

шлюзом, чтобы преобразовать вызовы его методов в обращения к внешнему источнику.

Одно из главных назначений шлюза — обеспечить основу для реализации фиктивных

служб (Service Stub, 519). Иногда для более удобного применения фиктивной службы в

структуру шлюза приходится вносить дополнительные изменения. Не бойтесь это делать:

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

значит, и написание системы.

Не стоит излишне усложнять шлюз — оставьте его настолько простым, насколько это

возможно. Реализуя данное типовое решение, сосредоточьте усилия на адаптации внеш-

ней службы к особенностям приложения и обеспечении хорошей основы для поддержки

фиктивных служб. Шлюз должен обрабатывать указанные задания и одновременно обла-

дать как можно меньшей функциональностью. Вся более сложная логика должна содер-

жаться в клиентах шлюза.

Зачастую для создания шлюзов применяют системы автоматической генерации кода.

Описав структуру внешнего источника, вы можете сгенерировать для него соответст-

вующий шлюз. Чтобы сконструировать оболочку для таблицы реляционной базы данных,

можно воспользоваться реляционными метаданными, а чтобы сгенерировать шлюз для

доступа к документу XML — схемами XML или шаблонами DTD. Разумеется, получен-

ные шлюзы не будут отличаться особым изяществом, однако выполнять свои функции

будут безотказно. Все остальные решения обычно оказываются более сложными.

Иногда реализацию шлюза рассматривают в терминах двух объектов — прикладной

части (back end) и интерфейсной части (front end). Прикладная часть шлюза представляет

собой минимальную оболочку функций доступа к внешнему источнику и вообще не уп-

рощает использование API. В свою очередь, интерфейсная часть преобразует неудобный

API в класс, оптимально приспособленный для применения конкретным приложением.

Данную стратегию хорошо применять в случаях, когда построение оболочки для доступа

к внешней службе и приспособление этой оболочки к нуждам приложения довольно

сложны, а потому требуют обработки каждого из этих заданий в отдельных классах. На-

против, если построение оболочки для доступа к внешней службе не отличается особой

сложностью, все перечисленные действия может выполнять и один класс.

Назначение

Типовое решение шлюз рекомендуется применять во всех случаях, когда интерфейс

доступа к внешнему источнику слишком неудобен. Наличие шлюза позволяет сконцен-

трировать все неудобные обращения в одном месте вместо того, чтобы распространять их

по всей системе. Применение шлюза не несет побочных эффектов, а код приложения

становится более читабельным и понятным.

Как уже отмечалось, шлюз значительно облегчает тестирование, поскольку представ-

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

Глава 18. Базовые типовые решения 485

внешней системы все в порядке, использование шлюза позволяет сделать первый шаг в

направлении реализации фиктивной службы.

Не менее важным преимуществом шлюза является возможность легко переключаться

между источниками данных. Дня перехода к другому источнику достаточно просто изме-

нить класс шлюза — оставшейся части системы это не коснется. Таким образом, шлюз

представляет собой простое и мощное средство инкапсуляции изменений. Иногда по-

требность в наличии подобной степени гибкости, а следовательно, и в реализации шлюза

кажется спорной. Тем не менее, даже если вы не собираетесь менять источник данных в

обозримом будущем, вы несомненно выиграете от простоты написания и тестирования

кода, которую обеспечивает данное типовое решение.

В качестве альтернативного варианта изолирования приложений от внешних источ-

ников может применяться преобразователь (Mapper, 489). Однако он имеет более слож-

ную структуру, нежели шлюз, а потому я предпочитаю использовать именно последний.

Некоторое время меня одолевали сомнения относительно того, стоит ли выделять

данную схему в самостоятельное типовое решение, противоположное существующим ти-

повым решениям интерфейс (Facade), адаптер (Adapter) и медиатор (Mediator) [20]. В конце

концов я решил описать шлюз как отдельное типовое решение, поскольку, на мой

взгляд, оно обладает рядом существенных отличий.

• Типовое решение интерфейс также упрощает работу с интерфейсом API, однако

оно создается самим разработчиком внешней службы и предназначено для общего

употребления. В свою очередь, шлюз разрабатывается клиентом для использова

ния конкретным приложением. Кроме того, интерфейс доступа, предоставляемый

объектом интерфейса, всегда отличается от интерфейса стоящего за ним объекта, в

то время как интерфейс шлюза может представлять собой точную копию инкапсу

лируемого интерфейса (для тестирования или замены источника данных сурро

гатным объектом).

• Типовое решение адаптер изменяет интерфейс некоторого объекта для достиже

ния соответствия с интерфейсом другого объекта. В отличие от него, интерфейс

шлюза не нужно подстраивать под какой-либо существующий интерфейс. Вообще

говоря, типовое решение адаптер можно применить, чтобы отобразить реализа

цию некоторого объекта на интерфейс шлюза. В этом случае объект адаптера будет

представлять собой составную часть реализации шлюза.

• Типовое решение медиатор разделяет множество объектов так, чтобы они не знали

о существовании друг друга, но были осведомлены о наличии объекта медиатора.

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

вовании шлюза.

Пример: создание шлюза к службе отправки сообщений (Java)

Обсуждая концепцию шлюза с моим коллегой Майком Реттигом (Mike Rettig), я уз-

нал, как он использовал данное типовое решение для обработки доступа к внешним ин-

терфейсам в приложениях EAJ (Enterprise Application Integration — интеграция корпора-

тивных систем). Мы решили, что опыт Майка может послужить прекрасной основой для

рассмотрения примера использования шлюза.

486 Часть II. Типовые решения

Как всегда, наш пример отличается невероятно простым положением дел. Мы созда-

дим шлюз к интерфейсу, который отсылает сообщение посредством службы отправки

сообщений. Сам интерфейс представляет собой единственный метод:

int send(String messageType, Object [] args));

Первый аргумент данного метода — это строка, указывающая на тип сообщения,

а второй — перечень аргументов самого сообщения. Система отправки сообщений по-

зволяет отсылать сообщения любого типа, поэтому ей нужен подобный универсальный

интерфейс. При настройке системы необходимо указать тип отсылаемых сообщений,

а также количество и типы аргументов этих сообщений. Таким образом, можно настро-

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

ния слово "CNFRM", а также задав аргумент orderiD ("идентификатор заказа") типа

String, аргумент amount ("количество товара") типа Integer и аргумент symbol ("код

товара") типа string. Система отправки сообщений проверяет типы передаваемых ар-

гументов и генерирует ошибку при попытке отослать сообщение неправильного типа или

сообщение правильного типа с неправильными типами аргументов.

Описанная схема обеспечивает высокую (и, кстати, весьма необходимую) степень

гибкости, однако универсальный интерфейс крайне неудобен в использовании. Из опре-

деления универсального интерфейса не ясно, какие типы сообщений допускается отсы-

лать, а также сколько и каких аргументов должно быть в каждом сообщении. Вместо

этого нам нужен интерфейс с методами наподобие следующего:

public void sendConfirmation(String orderiD, int amount,

String symbol);

В этом случае для отправки подтверждающего сообщения объектом домена необхо-

димо поступить так, как показано ниже.

class Order...

public void confirm() {

if (isValidO) Environment. getMessageGateway ().

sendConfirmation(id, amount, symbol); )

В приведенном фрагменте кода имя метода указывает на тип отсылаемого сообщения,

а для всех аргументов метода sendConf irmation явно заданы имена и типы. Разумеется,

данный метод вызывать намного легче, чем метод универсального интерфейса. В этом и

состоит смысл применения шлюза — обеспечить более удобный интерфейс для доступа к

внешней системе. Правда, при каждом добавлении или изменении типа отсылаемых со-

общений понадобится внести изменения и в класс шлюза, однако при отсутствии по-

следнего изменения коснулись бы вызывающего кода, поэтому общая сумма изменений

остается прежней. В этом плане применение шлюза более предпочтительно, так как по-

зволяет определить клиентов и перехватить потенциальные ошибки еще на этапе компи-

ляции.

Существует и другая проблема. При обнаружении ошибки универсальный интерфейс

возвращает ее код. Нуль означает отсутствие ошибок, а любое число, отличное от нуля,

Глава 18. Базовые типовые решения 487

указывает на определенный тип ошибки (при этом разным ошибкам соответствуют раз-

ные числа). Данная схема уведомления об ошибках вполне естественна для языка С, од-

нако в Java все обстоит иначе. Здесь для обработки ошибок применяются исключения,

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

Вместо того чтобы рассматривать все возможные типы ошибок, сконцентрируем

внимание только на двух из них: отправка сообщения неизвестного типа, а также отправка

сообщения, один из аргументов которого равен NULL. Возвращаемые коды ошибок

определены в интерфейсе системы отправки сообщений.

public static final int NULL_PARAMETER = -1;

public static final int UNKNOWN_MESSAGE_TYPE = -2;

public static final int SUCCESS = 0;

Природа первой и второй ошибок неодинакова. Ошибка, связанная с отправкой

сообщения неизвестного типа, указывает на неполадки в классе шлюза; клиент не мо-

жет привести к появлению подобной ошибки, поскольку вызывает только явные мето-

ды с заранее заданными типами сообщений. Тем не менее клиент может передать в ка-

честве аргумента значение NULL И привести к появлению второй ошибки, а именно

NULL_PARAMETER. Данная ошибка не нуждается в собственном исключении, так как яв-

ляется ошибкой программирования, — ситуации, для которых не пишут специальных

обработчиков. Вообще говоря, следить за появлением значений NULL МОГ бы и сам шлюз,

но повторять действия системы отправки сообщений не имеет смысла.

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

методов явного интерфейса в таковые универсального интерфейса, а коды ошибок —

в соответствующие исключения.

class MessageGateway. . .

protected static final String CONFIRM = "CNFRM";

private MessageSender sender;

public void sendConfirmation(String orderlD, int amount,

•^String symbol) {

Object [] args = new Object[]{orderlD, new

Integer(amount), symbol}; send(CONFIRM, args) ;

}

private void send(String msg, Object[] args) {

int returnCode = doSend(msg, args);

if (returnCode == MessageSender.NULL_PARAMETER)

throw new NullPointerException("Null Parameter passed

4t>for msg type:" + msg);

if (returnCode != MessageSender.SUCCESS)

throw new IllegalStateException( "Unexpected error

from messaging system #:" + returnCode);

protected int doSend(String msg, Object[] args) {

Assert.notNull(sender); return sender.send(msg,

args);

}

488 Часть II. Типовые решения

Пока назначение метода doSend весьма туманно, не так ли? Между тем не будем за-

бывать еще об одной не менее важной функции шлюза— облегчении тестирования.

При наличии шлюза тестирование объектов можно проводить без обращения к реальной

службе отправки сообщений. Для этого нужно создать фиктивную службу. В данном при-

мере МЫ определим класс MessageGatewayStub, КОТОрЫЙ наследует класс Message-

Gateway и переопределяет его метод doSend.

class MessageGatewayStub...

protected int doSend(String messageType, Object[] args) {

int returnCode = isMessageValid(messageType, args); if

(returnCode == MessageSender.SUCCESS) {

messagesSent++;

}

return returnCode;

}

private int isMessageValid(String messageType,

Object!] args) {

if (shouldFailAHMessages) return -999;

if (!legalMessageTypes().contains(messageType))

return MessageSender.UNKNOWN_MESSAGE_TYPE; for

(int i = 0; i < args.length; i++) { Object arg

= args [i]; if (arg == null) {

return MessageSender.NULL_PARAMETER; } }

return MessageSender.SUCCESS;

}

public static List legalMessageTypes() {

List result = new ArrayListO;

result.add(CONFIRM); return result; }

private boolean shouldFailAHMessages = false;

public void failAHMessages () {

shouldFailAHMessages = true; }

public int getNumberOfMessagesSent() {

return messagesSent;

}

Подсчет количества отправленных сообщений нужен для того, чтобы проверить, пра-

вильно ли работает шлюз. Для выполнения проверки можно воспользоваться приведен-

ными ниже тестами.

class GatewayTester...

public void testSendNullArg() {

try {

gate () .sendConfirmation(null, 5, "US");

fail("Didn't detect null argument"); }

catch (NullPointerException expected) {

Глава 18. Базовые типовые решения 489

assertEquals (0, gate().getNumberOfMessagesSent() ) ;

private MessageGatewayStub gate() {

return (MessageGatewayStub) Environment.getMessageGateway()

protected void setUpO throws Exception {

Environment.testlnit();

Как правило, шлюз располагают в таком месте, чтобы другом объектам было легко его

найти. В этом примере я воспользовался статическим интерфейсом окружения. Пере-

ключение между реальной и фиктивной службами можно осуществить во время настрой-

ки системы посредством типового решения дополнительный модуль (Plugin, 514). Кроме

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

GatewayTester, выполняющим инициализацию окружения.

В данном примере для замены реальной службы отправки сообщений я воспользовал-

ся классом, производным от класса шлюза. В качестве возможной альтернативы можно

рассмотреть создание класса, производного от самого класса службы, или же новую реа-

лизацию последней. При выполнении тестирования шлюз подсоединяется к фиктивной

службе отправки сообщений; данная схема срабатывает тогда, когда реализовать службу

заново не слишком сложно. Следует также отметить, что вместо замены службы можно

осуществить замену шлюза. Более того, некоторые разработчики умудряются заменять и

шлюз и службу, используя фиктивный шлюз для тестирования клиентов шлюза, а фик-

тивную службу — для тестирования самого шлюза.

Преобразователь (Mapper)

Объект, устанавливающий взаимодействие между двумя

независимыми объектами

Покупатель

Преобразователь

для пакета расценок

Пакет расценок

Предмет имущества

490 Часть II. Типовые решения

Иногда разработчику необходимо установить взаимодействие между двумя подсисте-

мами, которые не должны знать о существовании друг друга. Чаще всего это происходит,

если подсистемы не могут быть изменены или же их не следует связывать зависимостями

(напрямую или даже опосредованно через некоторый отдельный элемент).

Принцип действия

Типовое решение преобразователь представляет собой некий "изоляционный" слой,

проложенный между двумя подсистемами. Он управляет взаимодействием подсистем,

причем ни одна из них об этом даже не догадывается.

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

зации преобразователя понять принцип его работы совсем несложно. Самый непростой

аспект использования преобразователя — это его запуск, поскольку преобразователь не

может быть напрямую вызван одной из подсистем, которые он отображает друг на друга.

Иногда управление отображением, а значит, и вызов преобразователя возлагают на неко-

торую третью подсистему. Вместо этого преобразователь можно реализовать в виде типо-

вого решения обозреватель (Observer) [20], выполняющего роль "наблюдателя" за одной

из обслуживаемых систем. В этом случае преобразователь активизируется при перехвате

событий, сгенерированных этой системой.

Принцип работы преобразователя зависит от природы отображаемых слоев. Наиболее

распространенной разновидностью преобразователя является рассмотренный нами ра-

нее преобразователь данных (Data Mapper, 187), примеры использования которого можно

найти в главе 10 этой книги.

Назначение

Основное назначение преобразователя состоит в отделении друг от друга различных

частей программной системы. Похожие функции выполняет и шлюз (Gateway, 483). По-

следний применяется гораздо чаще, чем преобразователь, поскольку он намного проще и

в написании, и в последующем использовании.

Таким образом, преобразователь необходимо использовать только тогда, когда ни од-

на из отображаемых систем не должна зависеть от взаимодействия с другой системой.

Это действительно важно только в том случае, когда структура взаимодействия особенно

сложна и практически не связана с основным назначением каждой системы. Поэтому в

корпоративных приложениях главной областью применения преобразователя является

обслуживание взаимодействий с базой данных. Соответствующая разновидность преоб-

разователя получила название преобразователя данных.

Концепция преобразователя имеет немало общего с типовым решением медиатор

(Mediator) [20] в том плане, что оба они применяются для разделения независимых объ-

ектов. Тем не менее между данными типовыми решениями есть принципиальное разли-

чие. Объекты, использующие медиатор, знают о его наличии, даже если им неизвестно о

существовании друг друга. В свою очередь, объекты, разделенные преобразователем, не

знают о наличии последнего.

Глава 18. Базовые типовые решения 491

Супертип слоя (Layer Supertype)

Тип, выполняющий роль суперкласса для всех классов своего слоя

Довольно часто одни и те же методы дублируются во всех объектах слоя. Чтобы избе-

жать повторений, все общее поведение можно вынести в супертип слоя.

Принцип действия

Концепция супертипа слоя, а следовательно, и само типовое решение крайне просты.

Все, что от вас требуется, — это создать суперкласс для всех объектов слоя (например,

класс Domainobject, являющийся суперклассом для всех объектов домена в модели

предметной области (Domain Model, 140)). После этого в созданный суперкласс может

быть вынесено все общее поведение наподобие сохранения и обработки полей идентифи-

кации (Identity Field, 237). Точно так же все преобразователи данных (Data Mapper, 187),

образующие слой отображения, могут иметь общий суперкласс, работающий с супер-

классом объектов домена.

Если в рассматриваемом слое приложения находятся объекты нескольких различных

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

Назначение

Супертип слоя используется тогда, когда все объекты соответствующего слоя имеют

некоторые общие свойства или поведение. Поскольку в моих приложениях объекты слоев

имеют множество общих черт, применение супертипа слоя вошло у меня в привычку.

Пример: объект домена (Java)

Ниже приведен простенький суперкласс объектов домена, выполняющий обработку

их идентификаторов.

class DomainObject...

private Long ID;

public Long getlDO {

return ID;

}

public void setID(Long ID) {

Assert.notNull("Cannot set a null ID", ID);

this.ID =ID;

}

public DomainObject(Long ID) (

this.ID = ID;

public DomainObject() {

}

492 Часть II. Типовые решения

Отделенный интерфейс (Separated Interface)

Предполагает размещение интерфейса и его реализации

в разных пакетах

По мере разработки системы может возникнуть желание улучшить структуру послед-

ней, уменьшая количество зависимостей между ее частями. Управлять зависимостями

значительно удобнее, если классы будут сгруппированы в несколько пакетов. Выполнив

группировку, вы сможете установить правила, определяющие, могут ли классы одного

пакета обращаться к классам другого пакета, например правило, согласно которому

классы слоя домена не должны вызывать методы классов слоя представления.

Несмотря на это, клиенту может понадобиться осуществить вызовы методов, проти-

воречащие общей структуре зависимостей. В таком случае имеет смысл воспользоваться

типовым решением отделенный интерфейс, определив интерфейс в одном пакете, а реа-

лизовав в другом. Таким образом, клиент, которому нужно установить связь с интерфей-

сом, будет оставаться полностью независимым от его реализации. Отделенный интерфейс

представляет собой хороший объект для наложения шлюза (Gateway, 483).

Глава 18. Базовые типовые решения 493

Принцип действия

Суть данного типового решения очень проста. Оно основано на том, что реализация

зависит от своего интерфейса, но не наоборот. Это значит, что интерфейс и его реализа-

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

зависеть от пакета, содержащего интерфейс. Все другие пакеты приложения могут зави-

сеть от пакета, содержащего интерфейс, и при этом никак не зависеть от пакета, содер-

жащего реализацию.

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

должен иметь некоторую реализацию. Для этого можно воспользоваться отдельным паке-

том, который будет связывать интерфейс и реализацию во время компиляции, или же свя-

зать их во время настройки приложения посредством дополнительного модуля (Plugin, 514).

Интерфейс можно поместить в пакет клиента (как было показано на рисунке в начале

раздела) или же в отдельный пакет (рис. 18.1). Если реализация имеет только одного кли-

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

мещен прямо в пакете клиента. В связи с этим нелишне задуматься о том, отвечают ли

разработчики клиентского пакета за определение интерфейса? Размещение интерфейса в

пакете клиента указывает на то, что данный пакет будет принимать обращения от всех

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

сколько клиентских пакетов, интерфейс лучше поместить в отдельный пакет. Это реко-

мендуется делать и тогда, когда определение интерфейса не входит в обязанности разра-

ботчиков клиентского пакета (например, когда определением интерфейса занимаются

разработчики его реализации).

Рис. 18.1. Размещение отделенного интерфейса в собственном пакете

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

какими средствами языка программирования следует воспользоваться для описания ин-

терфейса Складывается впечатление, что при использовании языков наподобие Java и

С#, содержащих специальные интерфейсные конструкции, проще всего применить клю-

чевое слово interface. Как ни странно, это далеко не самый удачный выбор. В качестве

интерфейса лучше использовать абстрактный класс, чтобы допустить наличие общего, но

необязательного поведения.