endgültige Variablenzuweisung: bei der Deklaration oder im Konstruktor?

Question

Zunächst ist dies kein exaktes Duplikat von Initialize final variable before constructor in Java. Es ist wahrscheinlich verwandt, aber es gibt keine Antworten, die mich befriedigen.

Mein Problem ist über endgültige Variablen in Swing GUI's. Es geht um benutzerdefinierte Action s insbesondere. Ich habe eine Anzahl von final Variablen und eine Anzahl von static final Variablen.

Die Frage ist: Wenn die Variable tatsächlich eine Konstante ist, was ist besser: sie zur Konstruktionszeit initialisieren oder bei Deklaration initialisieren?

Die Antworten auf die Frage, die ich oben erwähnt habe, weisen generell darauf hin, dass die Variable static erstellt wird, sobald Sie sie bei der Deklaration zuweisen können. Das macht für mich keinen Sinn, da die Variablen nicht in einem statischen Kontext verwendet werden. Ich habe ein paar Bilder, die mein Formular wie Symbole verwendet, ich habe diese statisch gemacht, weil ein Bild einfach eine statische Sache ist, es sei denn, Ihre Anwendung modifiziert sie. Das macht Sinn.

Auf der anderen Seite sind die Action s neue Instanzen einer benutzerdefinierten inneren Klasse. Sehr technisch sind sie auch statisch, aber es fühlt sich einfach anders an. Sie müssen einfach nicht im statischen Kontext imo verfügbar sein. Also setze ich:

private final CustomAction customAction = new CustomAction(); 

Oder initialisiere ich es im Konstruktor? Welches ist besser? Oder denke ich den falschen Weg über static?

Answer 1

Wenn das Feld eine Konstante ist, macht es zu einem static final Mitglied der Klasse,

public class Foo{ 
    public static final int BAR = ...; 
} 

Andernfalls initialisieren das Feld in dem Konstruktor.

Answer 2

Initialisieren Sie Ihre konstanten Variablen bei der Deklaration: es ist lesbarer. Machen Sie es statisch, wenn es nicht sinnvoll ist, für verschiedene Instanzen der Klasse unterschiedliche Werte einzugeben, das heißt, wenn es sich um eine Variable auf Klassenebene und nicht um eine Instanzenebene handelt.

Answer 3

Für eine schnelle Anwendung starten und Programmteile der Benutzer möglicherweise nicht besuchen (Über Dialog), statische ist nicht gut. Im Allgemeinen ist statisch nicht sehr beliebt, wie Sie herausgefunden haben. Es gibt einige Gründe, aber nichts sehr überzeugend. Aber manchmal ist es ein Anti-Muster oder ein Zeichen dafür.

Noch in Ihrem Fall würde ich von statischen Bildern Abstand nehmen. Übrigens werden Ressourcen intern zwischengespeichert.

Answer 4

Ich denke, Sie sind auf dem richtigen Weg, es nicht statisch zu machen, weil es klingt wie Ihre CustomAction Objekte sind wirklich benutzerdefinierte auf die Instanz der GUI, die sie in seinem Konstruktor erstellt. Ich denke, ob Sie es im Konstruktor initialisieren oder nicht, hängt davon ab, ob Ihr Konstruktor eine CustomAction auf Basis der Eingabeargumente des Konstruktors anders initialisieren könnte.

Wo static im Vergleich zu nicht-statischen betrifft ... eine gute Faustregel ist, wenn eine Variable über alle Instanzen eines bestimmten Objekttyps konstant bleiben soll, dann sollte diese Variable static sein. Diese spart Speicher über die Laufzeit Ihres Programms und spart CPU-Zeit, wenn jede Objektinstanz erstellt wird, da diese Konstante nicht jedes Mal initialisiert werden muss, wenn Sie eine neue Instanz Ihres Objekts erstellen.Wenn andererseits eine Variable für eine bestimmte Instanz eines Objekts konstant bleibt, sich jedoch von Instanz zu Instanz unterscheiden kann, sollte sie nicht statisch sein.

Schließlich sollte final immer verwendet werden, wenn Sie nicht möchten, dass sich ein primitiver Wert oder eine Referenz auf ein Objekt jemals ändert. Der statische oder nicht statische Kontext beeinflusst nicht wirklich, ob eine Variable final sein sollte, es ist streng genommen final, weil der Entwickler diese Variable niemals ändern möchte. Der statische Kontext hängt ausschließlich davon ab, wie der Entwickler darauf zugreifen möchte.