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