Verständnis von "final" und "static"

[Timmorn]

Hallo,

ich habe da echt ein Verständnisproblem, das ich auch mit nachlesen (etwa in der Java Insel) nicht ganz beseitigen konnte.

Erstmal bin ich schon des öfteren auf die Meldung "overrideable method call in constructor" von Netbeans gestoßen. Warum diese Meldung kommt, konnte ich mit nachlesen klären: Es kann Probleme mit einer Subclass geben. Ein Bsp für diese Warunung:

public class SayIt {
    private static String Ausgabe;
    public SayIt (){
        setAusgabe("Der default Wert");
    }

    public String getAusgabe() {
        return Ausgabe;
    }

    public void setAusgabe(String out) {
        Ausgabe = out;
    }
}

Was aber nun der beste Weg ist das zu lösen, das checke ich noch nicht ganz. Ein final vor setAusgabe beseitigt ihn mal schnell. Aber ich verstehe nicht, ob das der richtige Weg ist, diesen Fehler zu vermeiden. Sollte ich vielleicht meine Klasse überhaupt anders angehen in so einem Fall?

Generell möchte ich eben, dass bei einer Klasse, bei Initialisierung bestimmte Funktionen das erste Mal ausgeführt werden (wie im Bsp oben), um so zusagen einen default Zustand zu haben. Und da scheint mir eben logisch, dies über den Constructor zu machen. Dann müsste ich aber all die verwendeten Funktionen auf final setzen?

Danke für die Hilfe,
Wolfgang

 

[XHelp]

Dazu läuft übrigens gerade im anderen Thread eine Diskussion ("immer getter/setter" o.ä.)
Man könnte ja von deiner Klasse ableiten und setAusgabe überschreiben. Dann würde der Konstruktor gänzlich etwas anderes machen.
P.S. bist du sicher, dass "ausgabe" static sein muss? Und Variablen sollte man klein schreiben

 

[KrokoDiehl]

Die Meldung sagt nur "das was du in einem Konstruktor aufrufst, kann von einer Subklasse überschrieben werden". Folgendes Beispiel:

class Oberklasse
{
    protected String name;
    
    public Oberklasse( String name )
    {
        setName(name);
    }    

    public void setName(String name)
    {
        this.name = name;
    }
}

class Unterklasse extends Oberklasse
{
    public Unterklasse(String name)
    {
        super(name);
    }

    @Override
    public void setName(String name)
    {
        this.name = "Ausgetrickst!";
    }
}

Dadurch dass die Methode

setName(String)

nicht final ist, kann man sie in Subklassen überschreiben. Hier überschreibt Unterklasse diese Methode und macht etwas völlig anderes, als erwartet: Sie setzt nicht den übergebenen Parameter als name! Daher:

Unterklasse unter = new Unterklasse("Max Muster");
// ...nun würde man erwarten, dass der Name "Max Muster" lautet, tatsächlich
// aber ist er "Ausgetrickst!"

Deswegen wird dies als Warnung behandelt. Es ist kein Programmfehler, aber womöglich eine Designschwäche ( ...zum Thema Setter gibts hier ohnehin schon genug Streitthemen :bae.

Das Wörtchen "final" behebt das Problem, weil final-Methoden nicht überschrieben werden dürfen.

*edit*
Ja, da fehlte ein "k" ...

 

[XHelp]

@KrokoDiehl
Vermutlich fehlt da ein "k" bei "ein Programmfehler"

 

[Michael...]

Erstmal bin ich schon des öfteren auf die Meldung "overrideable method call in constructor" von Netbeans gestoßen.
...
Was aber nun der beste Weg ist das zu lösen, das checke ich noch nicht ganz. Ein final vor setAusgabe beseitigt ihn mal schnell. Aber ich verstehe nicht, ob das der richtige Weg ist, diesen Fehler zu vermeiden.

Hab keine Ahnung von Netbeans aber die Meldung sagt ja nichts anderes, dass Du im Konstruktor eine Methode verwendest die (von Subklassen) überschrieben werden könnte.

Das final bewirkt, dass die Methode nicht mehr überschrieben werden kann, wenn es das ist was Du willst kann man das so machen.
Man kann aber auch die Variablen im Konstruktor direkt initialisieren.

Ansonsten: soll Ausgabe wirklich static sein? Alle Objekte dieser Klasse verwenden die selbe Variable!

 

[bygones]

ein einfache Regel:

Wenn deine Klasse nicht beim Erstellen für Vererbung gedacht ist, mach die Klasse final.

Nur wenn (und wirklich nur wenn), wenn die Klasse wirklich für die Vererbung frei gegeben ist, dann nicht final und keine Methoden im Konstruktor aufrufen - ansonsten Klassen immer final

 

[Timmorn]

Danke euch allen, ich verstehe es jetzt ganz gut denke ich. Vor allem die Erklärung von bygones war genau, was ich gesucht habe.