El patrón de 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 pedido devuelve la información necesaria para realizar una determinada tarea. [1] Los defensores del patrón dicen que el enfoque simplifica las aplicaciones basadas en componentes donde todas las dependencias se enumeran claramente al comienzo del diseño completo 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 anti-patrón.lo 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 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 quitando elementos de forma selectiva del localizador de servicios. Por ejemplo, una aplicación puede detectar que tiene una biblioteca mejor disponible 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 ellos se convierte en el registro.
- Una aplicación puede utilizar varios localizadores de servicios estructurados destinados a funciones / pruebas particulares. El localizador de servicios no exige una sola clase estática por proceso.
- La solución puede ser más sencilla con el localizador de servicios (frente a la inyección de dependencia) en aplicaciones con un diseño de servicio / componente bien estructurado. En estos casos, las desventajas pueden considerarse como una ventaja (por ejemplo, no es necesario suministrar varias dependencias a cada clase y mantener las configuraciones de dependencia).
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 (similar al uso de la inyección de dependencias ). Pero cada biblioteca está compilada, solo el descubrimiento de la Clase concreta podría no encontrarse y causar un error, es más un problema de implementación que un problema de 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 aplicaciones con una única interfaz de localización de servicios. El simulador se puede implementar para simular cada interfaz proporcionada por el localizador de servicios, por lo que es fácil intercambiar la implementación real con un simulador.
Ver también
Referencias
- ^ http://martinfowler.com/articles/injection.html#UsingAServiceLocator
- ^ Seemann, Mark. "El localizador de servicios es un anti-patrón" . blog.ploeh.dk . Consultado el 1 de junio de 2017 .
enlaces externos
- Código de muestra
- En defensa del localizador de servicios
- Patrones de programación de juegos: localizador de servicios
- Dependencias disfrazadas
- Mitos y truismos de la ingeniería de software