Werte von Member-Variablen erst im Konstruktor setzen?

[-frank]

private String lastWord = "<not set>;
private boolean saveHistory = true;

public SomeClass() {
    ..
}

vs.

private String lastWord;
private boolean saveHistory;

public SomeClass() {
    this.lastWord = "<not set>;
    this.saveHistory = true;
    ..    
}

ich setze die werte meist nicht erst im konstruktor. jetzt wo ich ein paar überlegungen zum sortieren von methoden/feldern/etc. gemacht habe (siehe http://www.java-forum.org/de/topic54635_wie-sortiert-eure-felder-methoden-etc.html) fällt mir aber natürlich auf, dass durch das umsortieren das verhalten des codes verändert werden könnte, was es mir wieder sinnvoller erscheinen lässt, dass doch in den konstruktor zu packen bzw. (bei vielen konstruktoren) in eine init-methode.
wie seht ihr das?

 

[bygones]

instanzvariablen werden im konstruktor gesetzt, statics beim definieren bzw im static block

 

[-frank]

instanzvariablen werden im konstruktor gesetzt, statics beim definieren bzw im static block

also instanzvariablen IMMER erst im konstruktor?

 

[ms]

instanzvariablen werden im konstruktor gesetzt, statics beim definieren bzw im static block

also instanzvariablen IMMER erst im konstruktor?

Es spricht nichts dagegen, bei der Definition der Variable diese gleich zu initialisieren.

 

[-frank]

Es spricht nichts dagegen, bei der Definition der Variable diese gleich zu initialisieren.

ja, also mir fiel jetzt eben auch nur das umsortieren ein. viele vorteile gibts aber auch nicht? gibts da garkeine richtlinie? (diverse konventionen bzw. codestyle-überprüfungsprogramme schreiben einem doch sonst auch alles vor )

 

[Leroy42]

DefaultTableModel theModel = new DefaultTableModel();
JTable table = new JTableModel(theModel);

Hier könnte eine alphabetischeSortierung der Membervariablen
zu unangenehmen Konsequenzen führen

Deshalb immer erst im Konstruktor in der
notwendigen Reihenfolge initialisieren! :meld:

(Obwohl ich mich selbst kaum daran halte;
ich initialisiere bei der Deklaration, solange
meine Initialisierungen keine Probleme machen )

 

[ms]

DefaultTableModel theModel = new DefaultTableModel();
JTable table = new JTableModel(theModel);

Hab das soeben getestet und war überrascht, dass es tatsächlich nicht nach der Abhängigkeit sortiert wird.
Die Abhängigkeit müßte schon berücksichtigt werden.

Dass die Reihenfolge bei Klassenvariablen bei der Initialisierung gegeben ist, ist imho ein fixer Bestandteil von Java.
Daher würde ich nie auf die Idee kommen, den Code alphabetisch zu sortieren.
Ich würde ja schließlich auch nie auf die Idee kommen den Code in einer Methode alphabetisch zu sortieren ???:L
Und das, wovon wir hier reden ist letztendlich Code.

Und deswegen die Klasse mit einem Konstruktor unnötigerweise vollramschen? Sicher nicht, wenns nicht absolut notwendig ist.
Ausserdem bringt imho eine alphabetische Sortierung nichts. => Ein richtig schönes Managerfeature.


ms

 

[-frank]

Ich würde ja schließlich auch nie auf die Idee kommen den Code in einer Methode alphabetisch zu sortieren ???:L
Und das, wovon wir hier reden ist letztendlich Code.

das war ja eigentlich die frage, die ich mir gestellt habe. klar ist es "code" und klar weiß man, in welcher reihenfolge das ganze abgearbeitet wird. aber es gibt ja in java so einiges, was zwar erlaubt ist aber eher als bad practice angesehen wird. hätte mir durchaus vorstellen können, dass komplexerer code außerhalb von methoden da durchaus dazugehört. aber naja, hab mich bisher auch nicht dran gehalten und wenn ihr auch keine nachteile seht außer, dass man beim sortieren probleme bekommen kann, dann ists wohl nicht so schlimm.