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

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

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

Дополнительный модуль (Plugin)

Дейвид Раис и Мэттью Фоммел

Связывает классы во время

настройки, а не во время компиляции

приложения

Типовое решение отделенный интерфейс (Separated Interface, 492) часто используют в

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

ет собственной реализации конкретного поведения. Большинство разработчиков обеспе-

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

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

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

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

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

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

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

менную окружения, определяет, находится ли приложение в режиме тестирования, и

возвращает нужный генератор первичного ключа. Чем больше методов-фабрик будет в

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

развертывания (например, "выполнять тестирование с использованием базы данных,

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

реальном режиме с использованием базы данных DB2 и полноценным управлением

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

новой сборки и нового развертывания приложения. В действительности процесс на-

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

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

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

ет централизованную настройку приложения во время выполнения.

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

Вначале нужно определить отделенный интерфейс для каждого поведения, которое

требует применения различных реализаций в зависимости от выбранной исполняющей

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

ка (Factory), несколько видоизменив его в соответствии с нашими требованиями. Реали-

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

зывания находились в единственной внешней точке. Это необходимо для облегчения

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

полняться не во время компиляции, а динамически, т.е. во время выполнения, чтобы из-

бежать повторной сборки приложения.

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

Правила связывания можно хранить в обычном текстовом файле. Метод-фабрика до-

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

прошенного интерфейса и возвращает эту реализацию (рис. 18.2).

Рис. 18.2. Получение вызывающим методом нужной реализации отделенного интерфейса

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

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

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

метода отражения файл настроек должен содержать отображения имен интерфейсов на

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

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

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

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

чие централизованной точки настройки значительно упрощает работу с приложением.

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

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

фабрика будет применять условную логику. Разумеется, в этом случае объект-фабрика

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

сложно- просто добавьте к объекту-фабрике новый параметр при добавлении нового

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

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

пакет.

Назначение

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

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

среды.

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

Пример: генератор идентификаторов (Java)

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

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

(рис. 18.3).

Рис. 18.3. Различные генераторы идентификаторов

Вначале опишем отделенный интерфейс idGenerator, а также все необходимые реа-

лизации.

interface IdGenerator... public Long nextld(); class

OracleldGenerator implements IdGenerator...

public OracleldGenerator() {

this.sequence = Environment.getProperty("id.sequence");

this.datasource = Environment.getProperty("id.source");

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

Реализация метода nextid() в классе OracleidGenerator возвращает следующий

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

заданном источнике данных.

class Counter implements IdGenerator...

private long count = 0;

public synchronized Long nextld() {

return new Long(count++); }

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

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

димые реализации.

class PluginFactory...

private static Properties props = new Properties ();

static {

try {

String propsFile = System.getProperty("plugins");

props.load(new FilelnputStream(propsFile) ) ; } catch

(Exception ex) {

throw new ExceptionlnlnitializerError(ex) ; }

}

public static Object getPlugin(Class iface) {

String implName = props.getProperty(iface.getName());

if (implName == null) {

throw new RuntimeException("implementation

not specified for " + iface.getName() + " in PluginFactory

properties."); } try {

return Class.forName(implName) .newlnstance() ; }

catch (Exception ex) {

throw new RuntimeException("factory unable to construct

instance of " + iface.getName());

}

Обратите внимание, что для загрузки нужной конфигурации мы обращаемся к сис-

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

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

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

настроек. Помещение имени файла настроек в системное свойство вместо явного ука-

зания пути в классе PluginFactory позволяет легко выбрать нужную конфигурацию

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

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

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

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

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

config file test.properties ...

# test configuration

IdGenerator=TestIdGenerator

config file prod.properties ...

# production configuration

IdGenerator=OracleIdGenerator

Давайте вернемся к интерфейсу idGenerator и добавим к нему статический атрибут

INSTANCE, значение которого будет определяться путем обращения к объекту Plugin-

Factory. Данный подход позволяет скомбинировать дополнительный модуль с типовым

решением единственный элемент (Singleton), чтобы метод получения идентификатора

выглядел как можно проще и читабельнее.

interface IdGenerator...

public static final IdGenerator INSTANCE =

(IdGenerator) PluginFactory.getPlugin(IdGenerator.class) ;

Теперь можно описать процесс получения идентификатора, зная, что дополнительный

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

class Customer extends DomainObject...

private Customer(String name, Long id) {

super(id) ;

this.name = name; } public Customer

create (String name) {

Long newObjId = IdGenerator.INSTANCE.nextld();

Customer obj = new Customer(name, newObjId);

obj.markNew ();

return obj;

}

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

Фиктивная служба (Service Stub)

Дейвид Райе

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

или проблемных служб на время тестирования

Функционирование большинства корпоративных приложений зависит от наличия

доступа к сторонним службам наподобие систем оценки кредитоспособности, определе-

ния налоговых ставок и ценообразования. Спросите любого разработчика корпоратив-

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

которые полностью контролируются кем-то другим. Кто знает, что случится с этими ре-

сурсами в будущем? Кроме того, поскольку большинство подобных служб являются уда-

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

Все эти проблемы, как минимум, замедляют процесс разработки приложения. Нередки

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

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

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

хуже (и к сожалению, весьма вероятно), зависимость приложения от внешних служб мо-

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

стью прервет процесс разработки.

Для ускорения и повышения качества процесса разработки реальную службу на время

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

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

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

Вначале нужно установить доступ к внешней службе с помощью шлюза (Gateway,

483). Последний следует реализовать не как класс, а в виде отделенного интерфейса

(Separated Interface, 492), имеющего одну реализацию для обращения к реальной службе

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

зация шлюза должна загружаться с помощью дополнительного модуля (Plugin, 514). Не за-

бывайте главный принцип написания фиктивной службы: она должна быть настолько

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

простой, насколько это возможно; излишняя сложность замедлит процесс разработки,

чего мы, собственно, и пытаемся избежать.

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

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

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

ствующем штате США, и величину налога на указанную сумму. Самый простой способ

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

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

телей.

Разумеется, настоящие законы налогообложения далеко не так просты. В некоторых

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

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

только с помощью реальной службы. Между тем большая часть функциональности на-

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

этому нужно усовершенствовать фиктивную службу, чтобы она учитывала подобные тон-

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

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

комбинацию товара и штата, и затем используем эту комбинацию во всех остальных ва-

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

все еще не превышает числа пальцев на одной руке.

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

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

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

надобилось бы не более 10 строк кода. Не забывайте: наша цель состоит именно в том,

чтобы ускорить процесс разработки, поэтому при любых обстоятельствах фиктивная

служба должна оставаться достаточно простой.

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

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

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

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

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

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

бенно если это делается во имя тестирования. Обязательно убедитесь, что реализация

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

во всех упомянутых методах во время тестирования.

Назначение

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

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

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

ребляют термин объект-имитатор (mock object), имея в виду не что иное, как фиктивную

службу. Мы считаем нужным употреблять именно термин "фиктивная служба", так как

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

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

Пример: служба определения величины налога (Java)

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

величины налога, развернутую в виде Web-службы. Вначале создадим шлюз, чтобы коду

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

Для облегчения загрузки будущих фиктивных служб шлюз будет реализован в виде отде-

ленного интерфейса. И наконец, загрузка необходимой реализации службы будет осуще-

ствляться

дополнительным модулем.

interface TaxService...

public static final TaxService INSTANCE =

(TaxService) PluginFactory.getPlugin(TaxService.class) ;

public Taxlnfo getSalesTaxInfo (String productCode, Address

addr, Money saleAmount);

Простая фиктивная служба, определяющая величину налога на основании единой

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

но ниже.

class FlatRateTaxService implements TaxService...

private static final BigDecimal FLAT_RATE = new BigDecimal(

"0.0500");

public Taxlnfo getSalesTaxInfо(String productCode, Address

addr, Money saleAmount) {

return new Taxlnfo(FLAT_RATE, saleAmount.multiply(

FLAT_RATE)); }

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

налогом, определенную комбинацию товара и штата.

class ExemptProductTaxService implements TaxService...

private static final BigDecimal EXEMPT_RATE = new BigDecimal(

"0.0000"); private static final BigDecimal FLAT_RATE = new

BigDecimal(

"0.0500");

private static final String EXEMPT_STATE = "IL";

private static final String EXEMPT_PRODUCT = "12300";

public Taxlnfo getSalesTaxInfо (String productCode, Address

addr, Money saleAmount) {

if (productCode.equals(EXEMPT_PRODUCT) &&

addr.getStateCode().equals(EXEMPT_STATE)) {

return new Taxlnfo(EXEMPT_RATE, saleAmount.multiply(

EXEMPT_RATE));

} else {

return new Taxlnfo(FLAT_RATE, saleAmount.multiply(

FLAT_RATE));

}

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

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

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

тирования. Обратите внимание: при наличии подобных методов в приведенной ниже

фиктивной службе нужно вернуться назад и добавить реализации этих же методов в более

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

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

ошибки подтверждения.

class TestTaxService implements TaxService...

private static Set exemptions = new HashSetO; public Taxlnfo

getSalesTaxInfо(String productCode, Address addr, Money

saleAmount) (

BigDecimal rate = getRate(productCode, addr); return

new Taxlnfo(rate, saleAmount.multiply(rate)); }

public static void addExemption(String productCode, String

stateCode) {

exemptions.add(getExemptionKey(productCode, stateCode)); }

public static void reset() {

exemptions.clear ();

}

private static BigDecimal getRate(String productCode, Address

addr) {

if (exemptions.contains(getExemptionKey(productCode,

addr.getStateCode()))) { return

EXEMPT_RATE; } else {

return FLAT_RATE; } }

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

службе определения величины налогов. Связывание интерфейса TaxService с упомяну-

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

для работы в реальных условиях. Еще одна конфигурация дополнительного модуля, пред-

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

приведенной выше фиктивной службой.

Как уже отмечалось, доступ объектов приложения к службе определения величины

налогов должен осуществляться посредством шлюза. Ниже приведен код класса Charge-

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

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

class ChargeGenerator...

public Charge[] calculateCharges(BillingSchedule schedule) {

List charges = new ArrayList(); Charge baseCharge = new Charge(

schedule.getBillingAmount() , false); charges.add(baseCharge) ;

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

Taxlnfo info = TaxService.INSTANCE.getSalesTaxInfо(

"^schedule.getProduct(), schedule.getAddress() ,

^schedule.getBillingAmount());

if (info.getStateRate().compareTo(

^>new BigDecimal (0) ) > 0) {

Charge taxCharge = new Charge(info.getStateAmount(),

^true) ;

charges.add(taxCharge); }

return (Charged) charges .toArray (

new Charge[charges.size()]); }

Множество записей (Record Set)

Представление табличных данных в оперативной памяти

На протяжении последних 20 лет основным способом долгосрочного хранения дан-

ных являются таблицы реляционных баз данных. Наличие горячей поддержки со сторо-

ны больших и малых производителей баз данных, а также стандартного (в принципе)

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

реляционные данные.

На гребне успеха реляционных баз данных рынок программного обеспечения по-

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

вательских интерфейсов. Все эти инфраструктуры основываются на использовании

реляционных данных и предоставляют наборы элементов управления, которые значи-

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

кого кода.

К сожалению, подобные средства имеют один существенный недостаток. Предостав-

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

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

Наличие каких-либо правил проверки, помимо простейших "правильны ли данные?", а

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

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

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