Java - ist das gute Programmierpraxis?

Question

Frage nur, ob das Folgende als gute Programmierpraxis gilt oder nicht? Ich mag es, meine individuellen Quelldateien so übersichtlich und übersichtlich wie möglich zu halten, aber ich frage mich, was erfahrenere Programmierer davon halten würden. Besonders gefällt mir die Idee der Settings.java-Klasse, alle meine "Magic Numbers" an einem Ort zu behalten. Hat jemand irgendwelche Vorschläge, wie ich Dinge verbessern könnte?

Glücklich Codierung :-)

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

Es ist nichts falsch daran, eine Einstellungsklasse zu haben; In Ihrem Beispiel sind die Einstellungen jedoch ziemlich ambivalent hinsichtlich des Rahmens, auf den sie angewendet werden, und auch nicht als tatsächliche Einstellungen, sondern als Standardwerte, die ausschließlich zur SwingApplication-Klasse gehören.

Eine andere Sache, über die wir nicht viel Kontrolle haben, ist, wie der Konstruktor in Swing in die Message-Pump-Schleife des Programms kaskadiert.

Für mich hat es nie Sinn mit einem Konstruktor gemacht, der nie zurückkehrt (es sei denn, der Rahmen ist geschlossen) und mehr als nur ein Objekt initialisiert.

Answer 2

Mit speziellen Klassen mit magischen Zahlen als statische Mitglieder eine gute Java Praxis ist.

Wenn Programme wachsen, können mehrere Einstellungsklassen mit jeweils beschreibenden Namen verwendet werden.

Answer 3

Macker bedeckt es gut. Darüber hinaus können Sie in der Zukunft einige der Einstellungen leicht in die tatsächlichen Benutzereinstellungen verschieben, um verschiedene Teile des Programms anzupassen. Da alle Ihre Einstellungen bereits in ihren eigenen Klassen isoliert sind, erfordert dies einen minimalen Aufwand von Ihnen.

Answer 4

Einige mögen es, all diese Sachen, die magischen Zahlen usw. in einer großen und hässlichen XML-Datei zu gruppieren, die zur Laufzeit gelesen (und verstanden) werden. Ihr Ansatz ist offensichtlich in Ordnung für ein kleines Projekt (z. B. allgemeine Kursarbeit), aber denken Sie an den offensichtlichen Vorteil, diese Einstellungen aus einer XML-Datei zu erhalten: Sie müssen Ihren Quellcode nicht neu kompilieren, um Änderungen an Ihren Einstellungen zu berücksichtigen :)

Answer 5

Ich denke, das kann eine gute Praxis sein, solange die Einstellungen wahrscheinlich nicht ändern und dokumentieren Sie die Beziehung zwischen den Einstellungen. Wenn sich diese Änderungen wahrscheinlich ändern, sind Konfigurationsdateien und/oder Befehlszeilenargumente sinnvoller, da sie keine Neukompilierung erfordern.

Answer 6

Sie verwenden, was einige Leute die "gefürchtete Konstanten Schnittstelle Antipattern" nennen, obwohl die Konstanten in der Regel in einer Schnittstelle sind, die importiert wird. Ich habe kein Problem damit, besonders seit dem Aufkommen von statischen Importen, aber vielleicht wird uns jemand auf die schrecklichen Übel stoßen. Einer von ihnen scheint zu sein "das ist nicht was Schnittstellen sind für".

Noch besorgniserregender ist, dass Sie Ihre GUI in einem Thread beginnen:

//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 Statik sind eine wirklich schlechte Idee. Bleib bei "Parametrierung von oben".

Es wurde direkt gefragt, aber der Beispielcode hat andere Probleme. Sie haben JFrame erweitert (eine schlechte Praxis), aber dann ignoriert und erstellt eine andere JFrame, um tatsächlich zu verwenden. Außerdem müssen Sie den Textbaustein einfügen, um immer auf die Swing-Komponenten des AWT Event Dispatch Thread (EDT) zugreifen zu können.

Answer 8

Wenn Sie Statik für Ihre magischen Zahlen verwenden, stellen Sie sicher, dass sie auch endgültig sind, wenn Sie meinen, dass sie sich nicht ändern.

Answer 9

Sie könnten JSR 296 (Swing Application Framework) für den Umgang mit Ihren GUI-Einstellungen/Start/Eigenschaften suchen.

Answer 10

Eine andere Lösung, die keine statischen Importe erfordert, wäre, eine vollständige "ApplicationSettings" -Klasse mit Feldern, Getter und Setter zu erstellen und eine Instanz dieser Klasse an den Konstruktor der Klasse zu übergeben, die die Parameter benötigt. Auf diese Weise können Sie ein Konfigurationsobjekt beibehalten, das leicht beibehalten oder geändert werden kann, wenn Sie die neue Größe speichern möchten, wenn der Benutzer beispielsweise die Größe des Fensters ändert.

Answer 11

Wie andere gesagt haben, ist dies durchaus gute Praxis, aber es gibt einige Dinge, die Sie den Code verbessern können:

• Geben Sie die Settings Klasse einen privaten Konstruktor ohne Argumente. Dies macht es unmöglich zu instanziieren und macht seine Absicht als ein Repository von Konstanten klarer. Die Einstellungen sollten final (unveränderlich) sowie static sein.
• Normalerweise werden Konstanten in Java LIKE_THIS statt likeThis geschrieben.
• Wenn Sie Java 1.5 oder höher verwenden, können Sie import static Settings.FRAME_WIDTH; in Ihren Klassen verwenden, um FRAME_WIDTH direkt verwenden zu können, anstatt Settings.FRAME_WIDTH schreiben zu müssen.

Damit endet Sie sich mit:

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

    static final int FRAME_WIDTH = 100; 

    static final int FRAME_HEIGHT = 200; 
}