Шаблон локатора сервисов

Шаблон локатора сервисов — это шаблон проектирования, используемый при разработке программного обеспечения для инкапсуляции процессов, связанных с получением сервиса, с сильным уровнем абстракции . В этом шаблоне используется центральный реестр, известный как «локатор служб», который по запросу возвращает информацию, необходимую для выполнения определенной задачи. ^[1] Сторонники шаблона говорят, что этот подход упрощает приложения на основе компонентов, в которых все зависимости четко перечислены в начале всего проекта приложения, что, следовательно, делает традиционное внедрение зависимостей более сложным способом соединения объектов. Критики шаблона утверждают, что это антишаблон , который скрывает зависимости и усложняет тестирование программного обеспечения. ^[2]^{[ нужен лучший источник ]}

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

«Локатор сервисов» может действовать как простой во время выполнения компоновщик . Это позволяет добавлять код во время выполнения без повторной компиляции приложения, а в некоторых случаях даже без его перезапуска.
Приложения могут оптимизировать себя во время выполнения, выборочно добавляя и удаляя элементы из локатора служб. Например, приложение может обнаружить, что оно имеет лучшую библиотеку для чтения изображений JPG, чем библиотека по умолчанию, и соответствующим образом изменить реестр.
Большие разделы библиотеки или приложения могут быть полностью разделены . Единственным связующим звеном между ними становится реестр.
Приложение может использовать несколько структурированных локаторов сервисов, предназначенных для определенных функций/тестирования. Локатор сервисов не требует наличия одного статического класса для каждого процесса.
Решение может быть проще с помощью локатора сервисов (вместо внедрения зависимостей) в приложениях с хорошо структурированным дизайном компонентов/сервисов. В этих случаях недостатки фактически можно рассматривать как преимущества (например, отсутствие необходимости предоставлять различные зависимости каждому классу и поддерживать конфигурации зависимостей).
Процесс определения местоположения услуги можно сделать чувствительным к области/контексту вызова, который может представлять конкретный бизнес-кейс. Вместо того, чтобы полагаться на фиксированный DI, который обычно предоставляет объекту его зависимости посредством передачи параметров конструктора, вызов местоположения службы может быть выполнен в бизнес-контексте по мере необходимости. Например, вы можете вызвать экземпляр «IShippingStrategy», полученный с помощью вызова местоположения службы, предоставив «ShippingContext» в качестве параметра для локатора службы, указывающего, что отправляется, откуда и куда, чтобы локатор службы мог соответствовать лучшему случаю. (например, с использованием оценки соответствия шаблону). Это значительно упрощает сложную архитектуру бизнес-приложений (например, медицинские системы оценки, маршрутизацию), где принятие обходных решений может осуществляться путем оценки стратегии наилучшего соответствия, расположенной динамически во время выполнения.

Недостатки

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

См. также

Ссылки

^ Фаулер, Мартин. «Инверсия управляющих контейнеров и шаблон внедрения зависимостей» .
^ Зееманн, Марк. «Локатор сервисов — это антипаттерн» . blog.ploeh.dk . Проверено 1 июня 2017 г.

Внешние ссылки

Пример кода

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

[1] Фаулер, Мартин. «Инверсия управляющих контейнеров и шаблон внедрения зависимостей» .

[2] Зееманн, Марк. «Локатор сервисов — это антипаттерн» . blog.ploeh.dk . Проверено 1 июня 2017 г.

[1]

[2]