Buenas prácticas de programación con variables de centralización

Question

¿Es una buena práctica de programación, al tratar con múltiples clases que necesitan la misma instancia de variables, crear una central?

chatWindow.variables.username = userField.getText(); 

Por ejemplo:

1. tengo una clase con una cantidad fija de variables
2. tengo otra clase que necesita las mismas variables
3. y otra que necesita las mismas variables como el primero

Así que tengo tres clases que usan todas la misma instancia de variables

I sólo crean la instancia de clase variable usando la primera clase (1)

I acceder a estas variables utilizando clases (2), (3) a través de la clase (1)

Ejemplo: (mientras en classTwo()):

classOne.variableClass.VariableName = false; 

EDITAR: en forma básica, mi pregunta es si está bien para hacer una "clase variable central y utilizar otras clases para acceder a la misma isntance de ella a través de un principal clase.

Sé que mi pregunta es difícil de entender, pero estoy seguro de que hay otra manera más fácil. Traté de pasar la misma instancia de la primera clase a través del constructor de la segunda y tercera clase, pero mi solución de alguna manera parecía más simple.

Answer 1

Esto huele feature envy ... suena como que algo anda mal con su modelo al hacer eso.

Si hay un grupo de variables que necesitan ser cambiado en múltiples clases, es probable que se convierta en un objeto (probablemente incluso una entidad). Pero debe considerar que si necesita cambiar estos valores en otras clases, es posible que deba poner algo de lógica en esa misma clase (para hacer comprobaciones de validación, etc.).

Tener una clase extra sólo para mantener las variables se considera generalmente un olor código, llamado dominio anémica. Sin embargo, hay casos que sí lo requieren, y podría ser una cuestión de gusto de todos modos. En ese caso, tu clase no es más que una estructura glorificada.

Answer 2

No parece que haya segregado sus clases de manera adecuada. Puede estar bien que las clases modifiquen otras variables de clase, pero evitaría tener un lugar donde almacene variables mutables. Eso hace que las cosas se vean como variables globales que son muy difíciles de manejar y que es mejor evitar. Ver here para más detalles sobre eso. Consulte también Law of Dementer, que ayuda a mantener el acoplamiento flojo en su programa.

Answer 3

No estoy muy seguro de lo que necesita debido a la falta de ejemplos, pero tal vez el patrón de registro es lo que necesita.

Básicamente, se crea una clase estática "global" que mantiene todas las variables que necesita a través de su aplicación

public abstract final class VarRegistry { 
    public static final String var1 = "val1"; 
    public static final int var2 = 2; 
} 

Ahora, en todas las clases que necesitan acceder a esas variables, se puede acceder y modificar fácilmente ellos:

VarRegistry.var1 = "test"; 

Espera sólo un segundo antes de ir codificación de esto: no es muy recomendable utilizar variables "globales" como este. Corrompe la encapsulación de datos, porque nunca se sabe cómo y cuándo cambian esas variables.

Es mejor reestructurar su programa para admitir patrones más seguros que activan correctamente sus datos, p. Inyección de dependencia.

Answer 4

Es una buena práctica usar la inyección de dependencia y pasar todos los recursos que necesita en lugar de que las clases encuentren lo que desean.

Uso de variables globales es más sencillo para empezar, pero a medida que crece su aplicación y desea utilizar las pruebas unitarias, estos son un verdadero dolor de cabeza, ya que se vuelve más difícil de manejar y mantener estos.

Answer 5

Cada problema tiene sus propios mejores compromisos, que debe plantearse una serie de preguntas. ¿Necesita (2) y (3) solo acceso listo para (1) o también necesitan acceso de escritura?

Lo que está haciendo en realidad (la creación de (2) y (3) a partir de (1) parece bueno, Builder, se crea istances que nunca se accede directamente)

Si se necesita acceso de escritura debería (2) ser notificado de los cambios hechos por (3) (o viceversa)?

En general, debe restringir la mayor cantidad posible de interacciones de "subclases" (idealmente es mejor evitar que algo se comparta, si es posible, pero generalmente lo es), así que acceder desde dentro (1) parece también mejor solución que acceder (1) desde (2) y (3).

Ese tipo de código del aumento de la restricción mantenibilidad, y elimina/reduce problemas como los valores cambian notificación, que posee quien etc.

Básicamente si los usuarios necesitan Warry sólo alrededor de (1) y todas las demás cosas se maneja internamente se ya están haciendo un buen trabajo (la fraseología Pimpl no te dice nada?)

También puedes tematizar (2) y (3) como extensiones a (1), actuando exactamente como un patrón de estrategia. con la ventaja de que solo (1) necesita preocuparse por las istancias, pero si en el futuro necesita continuar (1) ya tiene la estrategia lista para funcionar y puede actualizar con un mínimo esfuerzo. (Siempre noto que hay múltiples patrones siempre presentes en cada código que puedes escribir).

Al final, usted es el único que conoce todos los detalles del código, siempre preguntar si se puede mejorar la mantenibilidad código, fácil de leer, etc., donde se necesitan mejoras posibles etc.