Patrón de localizador de servicios

Patrones de diseño en el desarrollo de software

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 oscurece 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.

Desventajas

• El registro oculta las dependencias de la clase, lo que provoca errores en tiempo de ejecución en lugar de errores en tiempo de compilación cuando faltan dependencias (a diferencia de cuando se utiliza la inyección del constructor ). Pero cada biblioteca se compila, solo el descubrimiento de la clase concreta podría no encontrarse y provocar un error, es más un problema de implementación que un problema del localizador de servicios.
• 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 servicios global para establecer las dependencias falsas de una clase bajo prueba. Sin embargo, esto se supera fácilmente inyectando clases de aplicación con una única interfaz de localizador de servicios. Se puede implementar un simulador para simular cada interfaz proporcionada por el localizador de servicios, por lo que es fácil intercambiar la implementación real con un simulador.

Véase también

• Inyección de dependencia
• Principio de inversión de dependencia
• Interfaz de directorio y nombres de Java

Referencias

1. Fowler, Martin. "Contenedores de inversión de control y el patrón de inyección de dependencia".
2. Seemann, Marcos. "El localizador de servicios es un antipatrón". blog.ploeh.dk . Consultado el 1 de junio de 2017 .

Enlaces externos

• Código de muestra