Du kannst aber den Rüchgabewert der aufgerufenen Methoden final-Variablen zuweisen…
bye
TT
Aber deine initialisierungsmethode kann einen Rückgabewert haben.
public Bar(String baz){
this.foo = createFoo(baz);
}
private Foo createFoo(String baz){
...
return someFoo;
}
//an Stelle von
private void initFoo(String baz){
...
this.foo = someFoo;
}
weil man normalerweise keinen „laenger“ Dinge im Konstruktor machen sollte - No work in constructor !
@Timothy_Truckle , Majora:
Rückgabewerte an finale Klassenvariablen zuzuweisen nutze ich auch.
weil man normalerweise keinen „laenger“ Dinge im Konstruktor machen sollte - No work in constructor !
Naja, ich dachte da jetzt an Swing-Klassen, die eigentlich schon „im Konstruktor“ die Oberfläche erstellen, was aber in einer extra Methode ausgelagert ist, welche per EventQueue.invokeLater() ausgeführt wird. Spätestens da geht nichts mehr mit final, obwohl all diese Elemente einmal erstellt und nicht wieder verwendet werden. Und das ist schade, wenn auch nicht sonderlich schlimm, da diese Klassen keine Datenobjekte darstellen, auf die verschiedene Threads zugreifen o.ä.
Ich fände es einfach nur hübsch, wenn final etwas flexibler wäre. Andererseits könnte man dann die im Konstruktor fehlende Initialisierung nicht mehr anmeckern.
[QUOTE=Crian]Naja, ich dachte da jetzt an Swing-Klassen, die eigentlich schon “im Konstruktor” die Oberfläche erstellen, was aber in einer extra Methode ausgelagert ist[/QUOTE]Was spricht denn dagegen, diese Elemente schon bei der Deklaration zu initialisieren und in der vom Konstruktor aufgerufenen Methode nur noch zu konfigurieren?
bye
TT
Das stimmt, das ginge. Das hatte ich auch schon überlegt, fand es aber ziemlich hässlich, weil dann die zuständigen Codestellen auseinandergerissen werden.