¿Qué patrones de diseño se pueden aplicar al problema de los ajustes de configuración?


82

En productos de software grandes y complejos, la gestión de configuraciones configurables se convierte en un gran problema. Dos enfoques que he visto del problema son:

  • Haga que cada componente del sistema cargue su propia configuración desde los archivos de configuración o la configuración del registro.
  • Tener una clase de cargador de configuraciones que cargue todas las configuraciones del sistema configurables y que cada componente consulte el cargador de configuraciones para conocer sus configuraciones.

Ambos enfoques me parecen mal.

¿Existe algún patrón de diseño que pueda usarse para simplificar el problema? Quizás algo que aproveche la técnica de inyección de dependencia.


4
¿Por qué cree que la opción 2 es incorrecta?
ChaosPandion

2
Por lo general, se implementa como singleton, aunque hay otras formas de implementarlo.
Daniel Bingham

Respuestas:


47

Prefiero crear una interfaz para configurar consultas, cargar y guardar. Al usar la inyección de dependencia, puedo inyectar esto en cada componente que lo requiera.

Esto permite flexibilidad en términos de reemplazar la estrategia de configuración y proporciona una base común desde la que trabajar. Prefiero esto a un "cargador de configuración" global único (su opción 2), especialmente porque puedo anular el mecanismo de configuración para un solo componente si es absolutamente necesario hacerlo.


7
hola, será bueno si comparte alguna muestra :)
issamux

20

Actualmente trabajo en un sistema donde la configuración es administrada por un objeto singleton global que mantiene un mapa de claves de configuración a valores. En general, desearía que no se hubiera hecho de esta manera porque puede causar cuellos de botella de concurrencia en el sistema y es descuidado para las pruebas unitarias, etc.

Creo que Reed Copsey tiene el derecho de hacerlo (lo voté a favor), pero definitivamente recomendaría leer el excelente artículo de Martin Fowler sobre la inyección de dependencia:

http://martinfowler.com/articles/injection.html

Un pequeño apéndice también ... si desea hacer alguna prueba unitaria de tipo de objeto simulado, la inyección de dependencia es definitivamente el camino a seguir.


Parece que el decorador se adapta a tus necesidades. Puede crear un decorador serializable que podrá hacer clases serializables a su manera. La estrategia se puede utilizar para hacer que todos los objetos tengan su estrategia de serialización. Los objetos que no necesitan serializarse pueden usar la estrategia de ignorar. Aquellos que solo necesitan serializar sus campos, la estrategia OnlyFields y así sucesivamente. Usted ll be flexible with adding new things to your config. Sure as all approaches this have its pros y los contras.
Yaroslav Yakovlev

4

Qué tal esto. Usted define una interfaz Configurable con un solo método configure (configuración). El argumento de configuración es simplemente una tabla hash que asocia los nombres de los parámetros de configuración con sus valores.

Los objetos raíz pueden crear una tabla hash de configuración de la forma que deseen (por ejemplo, leerla desde un archivo de configuración). Esta tabla hash puede contener parámetros de configuración para el objeto raíz iselft, más cualquier parámetro que uno de sus componentes, subcomponentes, sub-subcomponentes (etc.) pueda utilizar.

A continuación, el objeto raíz invoca configure (configuración) en todos sus componentes configurables.


0

Puede crear una implementación múltiple de una interfaz que defina el cargador de configuración. Básicamente, patrón de estrategia donde puede definir una interfaz básica como configLoader y luego otras implementaciones diferentes como FileSystemLoader, ClasspathLoader, EnvVariablesLoader, etc. Detalles en este enlace

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.