Шаблон локатора услуг

Шаблон локатора услуг

редактировать

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

Содержание
  • 1 Преимущества
  • 2 Недостатки
  • 3 См. Также
  • 4 Ссылки
  • 5 Внешние ссылки
Преимущества
  • «Указатель службы» может действовать как простой время выполнения компоновщик. Это позволяет добавлять код во время выполнения без повторной компиляции приложения, а в некоторых случаях даже без его перезапуска.
  • Приложения могут оптимизировать себя во время выполнения, выборочно добавляя и удаляя элементы из локатор услуг. Например, приложение может обнаружить, что у него есть лучшая библиотека для чтения изображений JPG, чем библиотека по умолчанию, и изменить реестр соответствующим образом.
  • Большие разделы библиотеки или приложения могут быть полностью разделены. Единственной связью между ними становится реестр.
  • Приложение может использовать несколько структурированных локаторов сервисов, предназначенных для определенной функциональности / тестирования. Локатор сервисов не требует наличия одного статического класса для каждого процесса
  • Решение может быть проще с локатором сервисов (вместо внедрения зависимостей) в приложениях с хорошо структурированным дизайном компонентов / сервисов. В этих случаях недостатки можно фактически рассматривать как преимущество (например, отсутствие необходимости предоставлять различные зависимости каждому классу и поддерживать конфигурации зависимостей)
Недостатки
  • Реестр скрывает зависимости класса, вызывая время выполнения ошибки вместо ошибок времени компиляции, когда зависимости отсутствуют (аналогично использованию Внедрение зависимостей ). Но каждая библиотека компилируется, просто обнаружение конкретного класса может не быть найдено и вызвать ошибку, это скорее проблема развертывания, чем проблема локатора служб.
  • Реестр затрудняет выполнение кода проверки, поскольку все тесты должны взаимодействовать с одним и тем же глобальным классом локатора сервисов, чтобы установить поддельные зависимости тестируемого класса. Однако это легко преодолеть, внедрив классы приложений с помощью единого интерфейса локатора сервисов. Симулятор может быть реализован для имитации каждого интерфейса, предоставляемого локатором сервисов, поэтому можно легко заменить реальную реализацию симулятором.
См. Также
Ссылки
  1. ^http://martinfowler.com/articles/injection.html#UsingAServiceLocator
  2. ^Земанн, Марк. «Локатор услуг - это антишаблон». blog.ploeh.dk. Проверено 01.06.2017.
Внешние ссылки

.

Последняя правка сделана 2021-06-08 01:25:15
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Соглашение
О проекте