Enfoque correcto de las propiedades

Question

Estoy trabajando en Java en un proyecto bastante grande. Mi pregunta es acerca de cómo estructurar mejor el conjunto de propiedades para mi aplicación.

Método 1: Tener un objeto de propiedades estáticas al que puedan acceder todas las clases. (Desventajas: entonces, algunas clases pierden su generalidad si se las saca del contexto de la aplicación, sino que también requieren llamadas explícitas a un objeto estático que se encuentra en una clase diferente y puede desaparecer en el futuro, simplemente no lo hace). feel right, ¿estoy equivocado?)

Método 2: Haga que las propiedades sean instanciadas por la clase principal y transmitidas a las otras clases de aplicaciones. (Desventajas: termina pasando un puntero al objeto Propiedades para casi todas las clases y parece ser muy redundante y engorroso; no lo hago como)

¿Alguna sugerencia?

Answer 1

Me gusta usar Spring dependency injection para muchas de las propiedades. Puede tratar su aplicación como bloques de construcción e inyectar las propiedades directamente en el componente que las necesita. Esto preserva (fomenta) la encapsulación. Luego, ensamblas tus componentes y creas la "clase principal".

Un buen efecto secundario de la inyección de dependencia es que su código debería ser más fácilmente comprobable.

Answer 2

Parece que necesita un componente de administrador de configuración. Se encontraría a través de un tipo de localizador de servicios, que podría ser tan simple como ConfigurationManagerClass.instance(). Esto encapsularía toda esa diversión. O podría usar un marco de inyección de dependencia como Spring.

Mucho depende de cómo se encuentran los componentes en su arquitectura. Si sus otros componentes se pasan como referencias, hágalo. Solo sé consistente.

Answer 3

Normalmente voy por un objeto singleton que reside en un proyecto común y contiene una tabla hash de sí mismo con clave en el espacio de nombres, lo que resulta en una clase de propiedades para cada uno.

Dependency injection es también una buena forma de hacerlo.

Answer 4

En realidad, el enfoque 2 funciona muy bien.

Intenté usar un objeto de propiedades Singleton en un proyecto reciente. Luego, cuando llegó el momento de agregar funciones, necesito revisar el Singleton y lamenté tener que ubicar todos los lugares donde utilicé MySingleton.getInstance().

Aproximación 2 de pasar un objeto de información global a través de sus diversos constructores es más fácil de controlar.

El uso de un setter explícito ayuda, también.

class MyConfig extends Properties {...} 

class SomeClass { 
    MyConfig theConfig; 
    public void setConfi(MyConfig c) { 
     theConfig= c; 
    } 
    ... 
} 

Funciona bien, y le complacerá que controle con precisión qué clases realmente necesitan información de configuración.

Answer 5

Si las propiedades son necesarias para muchas clases, me gustaría obtener el enfoque 1. O tal vez una variante en la que utilice el patrón de diseño de Singleton en lugar de todos los métodos estáticos. Esto significa que no tiene que seguir pasando algunas propiedades alrededor del objeto. Por otro lado, si solo unas pocas clases necesitan estas propiedades, puede elegir el enfoque 2, por las razones que mencionó.También es posible que desee preguntarse qué tan probable es que las clases que escribe se vayan a reutilizar y, de ser así, qué tan problemático es reutilizar el objeto de propiedades. Si no es probable la reutilización, no se moleste con eso ahora y elija la solución más simple para la situación actual.

Answer 6

Me siento más cómodo cuando tengo un puntero estático para mis propiedades en memoria. algunas veces desea volver a cargar las propiedades en tiempo de ejecución u otra funcionalidad que sea más fácil de implementar con una referencia estática.

solo recuerda que ninguna clase es una isla. una clase reutilizable puede tener una clase de cliente para mantener el núcleo libre de la referencia singleteone.

También puede usar interfaces, solo intente no excederse.

Answer 7

Approache 2 es defenetly better.

De todos modos, no debe permitir otra búsqueda de clase a través del objeto config. Debería instalar las configuraciones de entrada en el objeto config fuera del objeto.

Eche un vistazo a apache commons configuration para obtener ayuda con la configuración Impl.

Así que en el main() que podría tener

MyObject mobj = new MyObject(); 
mobj.setLookupDelay(appConfig.getMyObjectLookupDelay); 
mobj.setTrackerName(appConfig.getMyObjectTrackerName); 

En lugar de

MyObject mobj = new MyObject(); 
mobj.setConfig(appConfig); 

donde appconfig es una envoltura alrededor de la biblioteca de configuración de Apache que hacer todo lo que la búsqueda de la base de valores en el nombre del valor en un archivo de configuración.

de esta manera su objeto se vuelve muy fácil de probar.

Answer 8

Si está buscando algo rápido puede usar las propiedades del sistema, están disponibles para todas las clases. Puede almacenar un valor String o si necesita almacenar una lista de 'cosas' puede usar el método System.Properties(). Esto devuelve un objeto 'Propiedades' que es una tabla Hash. Luego puede almacenar lo que quiera en la mesa. No es bonito, pero es una manera rápida de tener propiedades globales. YMMV

Answer 9

No he hecho Java por un tiempo, pero ¿no puede simplemente poner sus propiedades en las propiedades de java.lang.System? De esta forma, puede acceder a los valores desde cualquier lugar y evitar tener una clase de propiedad "global".