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

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

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

Наиболее неприятным моментом в использовании отделенного интерфейса является

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

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

ют отдельный объект-фабрику (factory object), интерфейс которого также реализован в

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

ции интерфейса, поэтому для обеспечения наиболее "безболезненной" связи применяют

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

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

стройки системы.

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

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

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

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

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

Назначение

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

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

ет в описанных ниже ситуациях.

• Если вы разместили в пакете инфраструктуры абстрактный код для обработки

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

• Если код одного слоя приложения должен обратиться к коду другого слоя, о суще

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

разователю данных (Data Mapper, 187».

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

бы ваш код зависел от интерфейсов API этих разработчиков.

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

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

Отделение интерфейсов от реализаций и сохранение их в разных пакетах требует допол-

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

фабрик (у которых есть собственные интерфейсы и реализации). Поэтому рекомендую

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

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

заций. Вообще говоря, разделение интерфейса и реализации, находящихся в одном паке-

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

отложено до тех пор, пока действительно не понадобится (если понадобится вообще).

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

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

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

ций этого достаточно. Неприятности наступают тогда, когда разработчику приходится

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

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

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

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

сыграть важную роль.

Как следует поступить, чтобы найти какой-нибудь объект? Обычно мы обращаемся к

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

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

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

нужных заказов. К сожалению, иногда просто не с чего начать поиск: например, когда

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

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

чтобы он стал доступным из разных частей приложения?

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

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

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

Проектирование реестра, как, впрочем, и любого другого объекта, должно рассматри-

ваться в терминах интерфейса и реализации. Как и у всех других объектов, интерфейс и

реализация реестра совершенно непохожи друг на друга, хотя многие почему-то думают,

что они должны быть одинаковы.

В качестве интерфейса реестров рекомендую применять статические методы. Стати-

ческий метод класса доступен всем объектам приложения. Более того, в статический ме-

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

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

объектов.

Эти идеи, однако, не означают, что данные реестра должны храниться в статических

полях. Вообще говоря, я не использую статические поля, если только их значения не яв-

ляются константами.

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

димости. Эти данные могут фигурировать в различных контекстах выполнения. Одни из

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

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

личных реализаций, однако интерфейс при этом может быть общий. Программист, пи-

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

ского метода — глобальные по отношению к процессу или по отношению к потоку.

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

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

ми разные области видимости.

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

Реестр (Registry)

"Глобальный " объект, который используется другими объектами

для поиска общих объектов или служб

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

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

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

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

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

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

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

типовое решение единственный элемент (Singleton) [20]. Последнее гарантирует, что в

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

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

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

чики явно обращаются к его содержимому (посредством методов наподобие Regis-

try.soleinstance.getFoo ()), однако я предпочитаю применять статический метод,

который скрывает от меня наличие единственного экземпляра объекта (Registry.get

Foo ()). Это особенно подходит для языков программирования, созданных на основе С,

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

объекта.

Объекты с единственным экземпляром хорошо применять в однопоточных приложе-

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

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

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

бы применить синхронизацию, однако трудность написания кода синхронизации может

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

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

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

объекты с единственным экземпляром хорошо подходят для хранения неизменяемых

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

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

по отношению к процессу, было бы нечто наподобие списка штатов США. Такие данные

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

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

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

ния процесса.

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

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

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

фичные по отношению к потоку, наподобие Java-классов ThreadLocal. Вместо этого

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

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

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

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

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

тод наподобие Registry. getDbConnection () будет Иметь одинаковый ВИД И ДЛЯ Тех

и для других данных.

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

ансу. Для работы с такими данными необходимо иметь идентификатор сеанса, который

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

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

к потоку. В этом случае для выполнения последующего доступа к данным сеанса объекты

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

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

ношению к потоку.

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

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

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

блем поможет прямое обращение к экземпляру потока.

Некоторым приложениям достаточно одного реестра, а некоторым может понадо-

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

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

пу использования, а не реализации.

Назначение

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

по отношению к определенному контексту. Я никогда не любил работать с глобальными

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

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

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

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

Существует несколько альтернатив использованию реестра. Одна из них состоит в

том, чтобы передавать глобальные данные в виде параметров. К сожалению, этот подход

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

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

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

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

тратой времени, поэтому в подобных ситуациях я отдаю предпочтение реестру.

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

нии экземпляров объектов добавлять к ним ссылки на необходимые глобальные данные.

Разумеется, при этом в конструкторе объекта появляется лишний параметр, однако он по

крайней мере не будет фигурировать в вызовах других методов. Как и предыдущий, этот

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

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

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

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

бавлении новых объектов. Вследствие этого многие предпочитают хранить глобальные

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

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

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

или сгенерированную документацию. Использование коллекции лишено таких пре-

имуществ. Чтобы понять, по какому ключу выполняется поиск, вам понадобится най-

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

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

Явный класс позволяет сохранить типовую безопасность в статически типизированных

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

темы ее можно было вынести в нужный класс или слой. Обычная коллекция не является

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

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

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

Как видите, необходимость в применении реестра все же возникает. Не забывайте,

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

нет неизбежным.

Пример: реестр с единственным экземпляром (Java)

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

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

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

(Row Data Gateway, 175). Логика запросов к базе данных будет инкапсулирована в специ-

альных методах поиска. Последние лучше реализовать в виде методов экземпляров объ-

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

Stub, 519). Объекты поиска нужно где-нибудь разместить и, очевидно, наиболее подхо-

дящим для этого является реестр.

Реестр с единственным экземпляром объекта представляет собой очень простой при-

мер типового решения единственный элемент (Singleton) [20]. Единственный экземпляр

объекта реестра хранится в статическом поле.

class Registry...

private static Registry getlnstance() {

return solelnstance; } private static Registry

solelnstance = new Registry!);

Все, что хранится в реестре, помещается в его экземпляр.

class Registry...

protected PersonFinder personFinder = new PersonFinder();

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

class Registry...

public static PersonFinder personFinder() {

return getlnstance().personFinder;

}

Чтобы заново инициализировать реестр, достаточно еще раз создать его единствен-

ный экземпляр.

class Registry...

public static void initialize () {

solelnstance = new RegistryO;

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

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

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

class RegistryStub extends Registry...

public RegistryStub() {

personFinder = new PersonFinderStub() ;

)

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

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

объекта Person.

class PersonFinderStub...

public Person find(long id) {

if (id == 1) {

return new Person("Fowler", "Martin", 10); }

throw new IllegalArgumentException("Can't find id: " +

String.valueOf(id));

}

Я поместил в реестр метод его инициализации в тестовом режиме. Впрочем, посколь-

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

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

class Registry...

public static void initializeStub() {

solelnstance = new RegistryStub(); }

Пример: реестр, уникальный в пределах потока (Java)

Мэттью Фоммел и Мартин Фаулер

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

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

шение хранилище потока (Thread Specific Storage) [35], реализуемое с помощью локаль-

ных переменных потока ThreadLocal. Эти переменные могут быть использованы для

создания реестра, уникального в пределах потока.

class ThreadLocalRegistry...

private static ThreadLocal instances = new ThreadLocalО;

public static ThreadLocalRegistry getlnstance() {

return (ThreadLocalRegistry) instances.get();

}

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

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

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

ницами транзакции или сеанса.

class ThreadLocalRegistry. . .

public static void begin() {

Assert.isTrue(instances.get() == null);

instances.set(new ThreadLocalRegistry() ) ; }

public static void end() {

Assert.notNull(getInstance() ) ;

instances.set(null) ;

}

Хранение объекта PersonFinder можно реализовать так же, как и в предыдущем

примере.

class ThreadLocalRegistry...

private PersonFinder personFinder = new PersonFinder();

public static PersonFinder personFinder() { return

getlnstance () .personFinder;

Все обращения к реестру извне будут обрамляться методами begin и end.

try {

ThreadLocalRegistry.begin ();

PersonFinder fl = ThreadLocalRegistry.personFinder();

Person martin = Registry.personFinder().find(1);

assertEquals("Fowler", martin.getLastName() ) ;

} finally (ThreadLocalRegistry.end(); }

Объект-значение (Value Object)

Небольшие простые объекты наподобие денежных значений

или диапазонов дат, равенство которых не основано

на равенстве идентификаторов

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

разницу между ссылочными объектами и объектами-значениями. Последние обычно

представляют собой небольшие объекты; они напоминают элементарные типы данных,

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

ориентированными.

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

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

Сформулировать различие между ссылочным объектом и объектом-значением доволь-

но сложно. В широком понимании этого слова объектами-значениями называют неболь-

шие объекты наподобие денежных значений или дат, а ссылочными — более крупные

объекты, например объект покупателя или объект заказа. Подобное определение доволь-

но удобно, однако весьма неформально.

Ключевым отличием объекта-значения от ссылочного объекта является принцип

проверки на равенство. Равенство ссылочных объектов определяется на основе равенства

их идентификаторов, например встроенных идентификаторов объектно-ориентирован-

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

объекты (таких, как первичные ключи реляционной базы данных). В свою очередь, ра-

венство объектов-значений определяется на основе равенства значений полей соответст-

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

чения дня, месяца и года.

Указанное различие отражается и в способе обработки объектов. Поскольку объекты-

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

ссылки на объект. В действительности никого не волнует, сколько объектов, соответст-

вующих 18 марта 2001 года, находится в системе в данный момент. Никого не волнует и

то, ссылаются ли эти объекты на один и тот же физический объект даты или же представ-

ляют собой различные экземпляры объекта с одинаковыми значениями полей.

Большинство языков программирования не содержат специальных средств для рабо-

ты с объектами-значениями. В этом случае для корректной обработки объекты-значения

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

не менялись. Это делается во избежание ошибок, связанных со ссылками на объекты.

Подобные ошибки возникают тогда, когда два объекта совместно используют один и тот

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

поля. В качестве иллюстрации рассмотрим небольшой пример. Пусть Мартин был при-

нят на работу 18 марта, и мы знаем, что Синди была принята на работу в тот же день.

Мы можем установить дату принятия на работу Синди равной дате принятия на работу

Мартина. Если теперь Мартин изменит эту дату на 18 мая, дата принятия на работу Синди

также будет изменена. Естественно, это совсем не то, чего ожидают многие из нас. Обычно

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

полную замену старого объекта новым. Данному принципу полностью отвечает концеп-

ция неизменяемых объектов.

Объекты-значения не следует хранить в виде отдельных записей базы данных. Как пра-

вило, для хранения объектов-значений применяют внедренные значения (Embedded

Value, 288) или крупные сериализованные объекты (Serialized LOB, 292). Поскольку объек-

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

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

значения.

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

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

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

наподобие Java, которые не содержат специальных средств для обработки объектов-

значений.

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

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

деньги (Money, 502).

ОСОБЕННОСТИ .NET-РЕАЛИЗАЦИИ

Платформа .NET содержит все необходимые средства для обработки объек-

тов-значений. В языке С#, чтобы пометить объект как объект-значение, доста-

точно указать в его объявлении ключевое слово struct, а не class. После

этого обработка указанного объекта будет проводиться исходя из семантики

значения.

Назначение

Типовое решение объект-значение следует применять для моделирования тех сущно-

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

объектов. Это особенно хорошо подходит для небольших, легких в создании объектов

наподобие денежных значений или диапазонов дат.

Совпадение названий

На протяжении довольно долгого времени данное типовое решение носило название

объекта-значения. К сожалению, несколько лет назад в сообществе J2EE [3] термин объ-

ект-значение (value object) стал применяться для обозначения типового решения объект

переноса данных (Data Transfer Object, 419), что вызвало настоящую бурю среди разработ-

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

сфере деятельности. Не так давно авторы книги [3] решили отказаться от использования

термина "объект-значение" и заменили его термином объект переноса (transfer object).

Я продолжаю использовать термин "объект-значение" в том смысле, в котором он

применяется в контексте данной книги. По крайней мере, так я не вступаю в противоре-

чие со своими предыдущими работами!

Деньги (Money)

Представляет денежное значение

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

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

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

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

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

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

ты выполняются в одной валюте, это не так уж сложно; однако, если используемых валют

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

курсах. Существует и более тонкий аспект, касающийся округления. Как правило, ре-

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

ты, что зачастую приводит к потере центов (или копеек, или других единиц вашей мест-

ной валюты) в результате ошибок округления.

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

ванного программирования и создадим типовое решение под названием деньги. Еще раз

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

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

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

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

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

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

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

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

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

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

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

щей валюты, например до центов. Несмотря на это, для выполнения некоторых вы-

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

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

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

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

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

дит по-своему.

Денежные величины представляют собой объекты-значения (Value Object, 500), по-

этому методы проверки на равенство и хэш-операции соответствующих объектов долж-

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

суммы и используемой валюте.

Обработка денежных величин подразумевает выполнение арифметических вычис-

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

ми числами. Несмотря на это, арифметические действия над денежными величинами

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

обычных чисел. Прежде всего, операции сложения и вычитания должны выполняться

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

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

зом отреагировать на нее. Самое простое (и самое распространенное) решение данной

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

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

ваться идеей "кошелька" (money bag), принадлежащей Вэрду Каннинхэму (Ward

Cunningham). Кошелек — это объект, содержащий денежные значения в разных валю-

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