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

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

  • haga que cada componente en el sistema cargue su propia configuración desde archivos de configuración o configuraciones de registro.
  • tener una clase de cargador de configuraciones que carga todas las configuraciones configurables del sistema y hacer que cada componente consulte el cargador de configuraciones para su configuración.

Estos enfoques me parecen incorrectos.

¿Hay algún patrón de diseño que pueda usarse para simplificar el problema? Tal vez algo que aproveche la técnica de dependency injection.

Prefiero crear una interfaz para establecer consultas, cargar y guardar. Al usar la dependency injection, 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 para que todo funcione. Prefiero esto a un único “cargador de configuración” global (su opción 2), especialmente porque puedo anular el mecanismo de configuración para un solo componente si es absolutamente necesario hacerlo.

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

Creo que Reed Copsey tiene derecho (lo voté), pero definitivamente recomendaría leer el gran artículo de Martin Fowler sobre la dependency injection:

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

Una pequeña adición también … si quieres hacer una prueba de unidad de tipo de objeto simulado, la dependency injection es definitivamente el camino a seguir.

Qué tal esto. Usted define una interfaz configurable con un único método de configuración (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, leyéndola 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 pueda usar uno de sus componentes, subcomponentes, subcomponentes (etc.).

El objeto raíz invoca a continuación la configuración (configuración) en todos sus componentes configurables.