Java - ¿Es esta una buena práctica de programación?

Question

¿Solo me pregunto si lo siguiente se considera una buena práctica de programación o no? Me gusta mantener mis archivos fuente individuales lo más concisos y despejados posible, pero me pregunto qué pensarían los codificadores más experimentados. Me gusta especialmente la idea de la clase Settings.java para mantener todos mis "Números Mágicos" en un solo lugar. ¿Alguien tiene alguna sugerencia sobre cómo podría mejorar las cosas?

:-) codificación feliz

class ApplicationLauncher 
{ 
    public static void main(String[] args) 
    { 
     SwingApplication mySwingApplication = new SwingApplication(); 
    } 
} 

////////////// 

import javax.swing.*; 

public class SwingApplication extends JFrame 
{ 
    public SwingApplication() 
    {  
     JFrame myJFrame = new JFrame(); 
     myJFrame.setSize(Settings.frameWidth, Settings.frameHeight); 
     myJFrame.setVisible(true);  
    } 
} 

////////////// 

class Settings 
{ 
    static int frameWidth = 100; 
    static int frameHeight = 200; 
} 

Answer 1

No hay nada de malo en tener una clase de configuración; sin embargo, en su ejemplo las configuraciones son bastante ambiguas en términos de qué marco se aplican, tampoco son configuraciones reales, sino valores predeterminados que pertenecen estrictamente a la clase SwingApplication.

Otra cosa sobre la que no tenemos mucho control es cómo llama el constructor en las cascadas Swing al bucle de bomba de mensajes del programa.

Para mí, nunca ha tenido sentido con un constructor que nunca regresa (a menos que el marco esté cerrado) y hace algo más que inicializar un objeto.

Answer 2

que tienen clases especiales con números mágicos como miembros estáticos es una buena práctica de Java.

A medida que los programas crecen, se pueden usar múltiples clases de configuración, cada una con nombres descriptivos.

Answer 3

Macker lo cubrió bien. Además, hacerlo de esta manera le permitirá, en el futuro, mover algunas de las configuraciones fácilmente a las preferencias reales del usuario para que puedan personalizar diferentes partes del programa. Dado que todas sus configuraciones ya están aisladas en sus propias clases, esto requerirá una cantidad mínima de esfuerzo de su parte.

Answer 4

A algunos les gusta agrupar todo esto, los números mágicos, etc. en un archivo XML grande y feo que se leerá (y tendrá sentido) en tiempo de ejecución. Su enfoque obviamente está bien para un proyecto pequeño (por ejemplo, trabajo general) pero piense en la ventaja obvia de obtener estos ajustes de un archivo XML: no necesitará recompilar su código fuente para reflejar los cambios realizados en su configuración :)

Answer 5

Creo que puede ser una buena práctica siempre que la configuración no cambie y documente la relación entre las configuraciones. Si es probable que esto cambie, entonces los archivos de configuración y/o los argumentos de la línea de comando tienen más sentido, ya que no requieren una recompilación.

Answer 6

Está utilizando lo que algunos llaman el "antipatrón de interfaz de constantes temidas", aunque generalmente las constantes se encuentran en una interfaz que se importa. No tengo ningún problema con eso, especialmente desde el advenimiento de las importaciones estáticas, pero tal vez alguien nos contará sobre los terribles males. Uno de ellos parece ser "para eso no son las interfaces".

De mayor preocupación es que usted debe estar comenzando su interfaz gráfica de usuario en un hilo:

//Schedule a job for the event-dispatching thread: creating 
    //and showing this application's GUI. 
    SwingUtilities.invokeLater(new Runnable() { 
      public void run() { 
       JFrame myJFrame = new JFrame(); 
       myJFrame.setSize(Settings.frameWidth, Settings.frameHeight); 
       myJFrame.setVisible(true); 
      } 
     }); 

Answer 7

estática mutables es realmente una mala idea. Quédate con "Parametrización desde Arriba".

Se lo preguntaron directamente, pero el código de ejemplo tiene otros problemas. Has extendido JFrame (una mala práctica), pero luego ignoró eso y creó otro JFrame para usarlo realmente. También necesita incluir la plantilla estándar para acceder siempre a los componentes Swing en AWT Event Dispatch Thread (EDT).

Answer 8

Si va a usar estática para sus números mágicos, asegúrese de que también sean definitivos, si quiere decir que no cambien.

Answer 9

Es posible que desee consultar JSR 296 (Swing Application Framework) para tratar con la configuración de su GUI/inicio/propiedades.

Answer 10

Otra solución, que no requiere importaciones estáticas, sería crear una clase completa "ApplicationSettings" con campos, getters y setters, y pasar una instancia de esta clase al constructor de la clase que necesita los parámetros. Esto le permite mantener un objeto de configuración que puede conservarse o modificarse fácilmente si desea guardar el nuevo tamaño si el usuario cambia el tamaño de la ventana, por ejemplo.

Answer 11

Como otros han dicho, esto es perfectamente buena práctica, pero hay algunas cosas que puede hacer para mejorar el código:

• dar a la clase Settings un constructor sin argumentos privado. Esto hace que sea imposible crear una instancia y hace que su intento como un depósito de constantes sea más claro.
• La configuración debe ser final (inmutable), así como static.
• Normalmente, las constantes en Java se escriben LIKE_THIS en lugar de likeThis.
• Si está utilizando Java 1.5 o posterior, puede usar import static Settings.FRAME_WIDTH; en sus clases para poder usar FRAME_WIDTH directamente en lugar de tener que escribir Settings.FRAME_WIDTH.

Esto termina con:

class Settings 
{ 
    /** Do not instantiate! */ 
    private Settings() {} 

    static final int FRAME_WIDTH = 100; 

    static final int FRAME_HEIGHT = 200; 
}