Patrón de diseño de configuración en el sistema Java

Question

La pregunta es vieja: ¿cuál es el diseño adecuado para admitir un archivo de configuración o configuraciones de sistema en nuestro sistema? He identificado los siguientes requisitos:

• debe ser capaz de recargar en vivo y tener cambios recogidos al instante, sin volver a desplegar
• Para las aplicaciones de software que se basan en el mismo, por ejemplo, SQL o credenciales memcached, debe ser posible introducir el cambio en un lugar aislado y desplegar de una sola vez, incluso si las aplicaciones son en máquinas separadas en lugares separados
• Muchos procesos/equipos que ejecutan la misma aplicación soportada

y las partes de este diseño soy s compitiendo con:

• ¿Debería cada clase principal tener su propia clase "Config" como un parámetro de entrada para el constructor? ¿Debería haber una fábrica responsable de instanciar con respecto a la configuración correcta? ¿O debería cada clase simplemente leer desde su propia configuración y volver a cargar de forma automática?
• Si la clase B deriva de la clase A, o se compone a su alrededor, ¿tendría sentido que se heredara el archivo de configuración?
• Digamos que la clase A está construida por M1 y M2 (M por "main") y M1 es responsable de crear instancias de un recurso. Supongamos que el recurso se basa en las credenciales de MySQL que espero que sean comunes entre M1 y M2, ¿hay alguna manera de evitar la compensación de la propiedad de interrupción y poner en la configuración de A v v. Duplicar el recurso en la configuración de M1 y M2?

Estos son los problemas de diseño que estoy tratando ahora y realmente no conozco los patrones de diseño o los marcos que funcionan aquí. Estoy en Java, así que cualquier biblioteca que resuelva esto es muy bienvenida.

Answer 1

Es posible que desee comprobar Apache Commons Config, que proporciona una amplia gama de funciones. Puede especificar múltiples fuentes de configuración y organizarlas en una jerarquía. Una característica de particular interés es la provisión para Configuration Events, que permite a sus componentes registrar su interés en los cambios de configuración.

El objetivo de cambiar la configuración sobre la marcha es seductor, pero requiere algo de reflexión sobre el diseño. Debe administrar esos cambios cuidadosamente (por ejemplo, ¿qué sucede si reduce el tamaño de las colas? ¿Desecha los elementos existentes en la cola?)

Answer 2

Cada clase principal debería tener su propia clase "Config" como parámetro de entrada al ¿constructor?

No, eso suena como un diseño horrible que complicaría innecesariamente una gran cantidad de código. Le recomendaría implementar una clase de Configuración global como singleton. Singleton significa que solo hay un objeto de configuración, que es una variable estática privada de su clase de configuración y se puede adquirir con un método público estático getInstance() siempre que sea necesario.

Este objeto de configuración debe almacenar todos los parámetros de configuración como pares clave/valor.