Diagrama de clases UML del patrón localizador de servicios.
El patrón localizador de servicios es un patrón de diseño utilizado en el desarrollo de software para encapsular los procesos involucrados en la obtención de un servicio con una fuerte capa de abstracción . Este patrón utiliza un registro central conocido como "localizador de servicios", que, a petición, devuelve la información necesaria para realizar una determinada tarea. [1] Los defensores del patrón afirman que el enfoque simplifica las aplicaciones basadas en componentes en las que todas las dependencias se enumeran de forma clara al principio de todo el diseño de la aplicación, lo que hace que la inyección de dependencias tradicional sea una forma más compleja de conectar objetos. Los críticos del patrón argumentan que es un antipatrón que oculta las dependencias y hace que el software sea más difícil de probar. [2] [ se necesita una mejor fuente ]
Ventajas
El "localizador de servicios" puede actuar como un simple enlazador en tiempo de ejecución . Esto permite agregar código en tiempo de ejecución sin tener que volver a compilar la aplicación y, en algunos casos, sin tener que reiniciarla.
Las aplicaciones pueden optimizarse en tiempo de ejecución agregando y eliminando elementos de forma selectiva del localizador de servicios. Por ejemplo, una aplicación puede detectar que tiene una biblioteca mejor para leer imágenes JPG que la predeterminada y modificar el registro en consecuencia.
Se pueden separar por completo grandes secciones de una biblioteca o aplicación . El único vínculo entre ellas es el registro.
Una aplicación puede utilizar varios localizadores de servicios estructurados destinados a una determinada funcionalidad o prueba. El localizador de servicios no exige una única clase estática por proceso.
La solución puede ser más sencilla con el localizador de servicios (en lugar de la inyección de dependencias) en aplicaciones con un diseño de componentes/servicios bien estructurado. En estos casos, las desventajas pueden considerarse en realidad como una ventaja (por ejemplo, no es necesario proporcionar varias dependencias a cada clase y mantener configuraciones de dependencias).
El proceso de ubicación de servicio puede hacerse sensible a un contexto/ámbito de llamada que puede representar un caso de negocio específico. En lugar de depender de un DI fijo que normalmente proporciona un objeto con sus dependencias a través de un paso de parámetros del constructor, la llamada de ubicación de servicio puede realizarse en un contexto de negocio según sea necesario. Por ejemplo, puede desear invocar una instancia "IShippingStrategy" obtenida a través de una llamada de ubicación de servicio, proporcionando un "ShippingContext" como parámetro al localizador de servicio que indica qué se está enviando desde dónde y a dónde, de modo que el localizador de servicio pueda coincidir con el mejor caso (por ejemplo, utilizando una puntuación de coincidencia de patrones). Esto simplifica significativamente la arquitectura de aplicaciones de negocio complejas (por ejemplo, sistemas de puntuación médica, enrutamiento) donde la toma de decisiones indirecta se puede realizar a través de la puntuación de la mejor estrategia coincidente ubicada dinámicamente en un tiempo de ejecución.
El registro hace que el código sea más difícil de probar , ya que todas las pruebas deben interactuar con la misma clase de localizador de servicio global para establecer las dependencias falsas de una clase bajo prueba.
