Java - Est-ce une bonne pratique de programmation?

Question

Je me demande simplement si ce qui suit est considéré comme une bonne pratique de programmation ou non? J'aime garder mes fichiers source individuels aussi concis et concis que possible, mais je me demande ce que les codeurs les plus expérimentés penseraient. J'aime particulièrement l'idée de la classe Settings.java pour conserver tous mes "numéros magiques" au même endroit. Quelqu'un at-il des suggestions sur la façon dont je pourrais améliorer les choses?

:-) Bonne codage

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

Il n'y a rien de mal à avoir une classe de paramètres; Cependant, dans votre exemple, les paramètres sont plutôt ambigus en termes de cadre auquel ils s'appliquent, ils ne sont pas non plus des paramètres réels, mais plutôt des valeurs par défaut qui appartiennent strictement à la classe SwingApplication.

Une autre chose sur laquelle nous n'avons pas beaucoup de contrôle est la manière dont le constructeur appelle les cascades Swing dans la boucle de pompage du message du programme.

Pour moi, cela n'a jamais été logique avec un constructeur qui ne retourne jamais (sauf si le cadre est fermé) et fait plus qu'initialiser un objet.

Answer 2

avec des classes spéciales ayant des nombres magiques en tant que membres statiques est une bonne pratique de Java. Au fur et à mesure que les programmes se développent, plusieurs classes de paramètres, chacune avec des noms descriptifs, peuvent être utilisées.

Answer 3

Macker l'a bien couvert. De plus, le faire de cette façon vous permettra, à l'avenir, de déplacer facilement certains paramètres dans les préférences réelles de l'utilisateur afin qu'ils puissent personnaliser différentes parties du programme. Puisque tous vos paramètres sont déjà isolés dans leurs propres classes, cela nécessitera un minimum d'effort de votre part.

Answer 4

Certains aiment regrouper tous ces trucs, les nombres magiques etc ... dans un gros fichier XML moche qui sera lu (et compris) à l'exécution. Votre approche est évidemment acceptable pour un petit projet (par exemple cours général) mais pensez à l'avantage évident d'obtenir ces paramètres à partir d'un fichier XML: vous n'aurez pas besoin de recompiler votre code source pour refléter les modifications apportées à vos paramètres :)

Answer 5

Je pense que cela peut être une bonne pratique tant que les paramètres ne sont pas susceptibles de changer et que vous documentez la relation entre les paramètres. Si ceux-ci sont susceptibles de changer, alors les fichiers de configuration et/ou les arguments de ligne de commande ont plus de sens, car ils ne nécessitent pas de recompilation.

Answer 6

Vous utilisez ce que certains appellent "l'antipattern de l'interface des constantes redoutées", bien que généralement les constantes soient dans une interface importée. Cela ne me pose aucun problème, surtout depuis l'avènement des importations statiques, mais peut-être que quelqu'un nous parlera des terribles maux. L'un d'eux semble être "ce n'est pas ce que sont les interfaces".

plus préoccupant est que vous devriez commencer votre interface graphique dans un thread:

//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

Mutable sont une statics très mauvaise idée. Stick avec "Paramétrage d'en haut".

Il a été directement demandé, mais l'exemple de code a d'autres problèmes. Vous avez étendu JFrame (une mauvaise pratique), mais ensuite ignoré cela et créé un autre JFrame à utiliser réellement. De plus, vous devez inclure la plaquette standard pour toujours accéder aux composants Swing sur le Thread Thread Dispatch (EDT) AWT.

Answer 8

Si vous utilisez des statistiques pour vos nombres magiques, assurez-vous qu'elles sont également finales, si vous voulez qu'elles ne changent pas.

Answer 9

Vous voudrez peut-être regarder dans JSR 296 (Swing Application Framework) pour traiter vos paramètres GUI/lancement/propriétés.

Answer 10

Une autre solution, qui ne nécessite pas d'importations statiques, serait de créer une classe "ApplicationSettings" complète avec champs, getters et setters, et de passer une instance de cette classe au constructeur de la classe qui a besoin des paramètres. Cela vous permet de conserver un objet de configuration qui peut facilement être conservé ou modifié si vous souhaitez enregistrer la nouvelle taille si l'utilisateur redimensionne la fenêtre, par exemple.

Answer 11

Comme d'autres l'ont dit, cela est tout à fait bonne pratique, mais il y a certaines choses que vous pouvez faire pour améliorer le code:

• donner à la classe Settings un constructeur sans argument privé. Cela rend impossible l'instanciation et rend plus clair son intention en tant que référentiel de constantes.
• Les paramètres doivent être final (immuable) ainsi que static.
• En règle générale, les constantes dans Java sont écrites LIKE_THIS plutôt que likeThis.
• Si vous utilisez Java 1.5 ou supérieur, vous pouvez utiliser import static Settings.FRAME_WIDTH; dans vos classes pour pouvoir utiliser directement FRAME_WIDTH au lieu de devoir écrire Settings.FRAME_WIDTH.

Cela vous finit avec:

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

    static final int FRAME_WIDTH = 100; 

    static final int FRAME_HEIGHT = 200; 
}