Frage zu statischen Variablen bei Vererbung

[Guest]

Hallo, mal folgende Frage:

Angenommen ich habe die Klasse SuperClass mit einer statischen Variable "instance" vom Typ SuperClass. Außerdem habe ich eine Klasse SubClass, die ich von SuperClass ableite. Handelt es sich nun bei der Variable "instance" von SuperClass um die selbe wie die von SubClass?

Mfg

 

[Marco13]

Ja. Außer, wenn du in SubClass nochtmal eine neue instance-Variable anlegst.

 

[tfa]

Hallo, mal folgende Frage:

Angenommen ich habe die Klasse SuperClass mit einer statischen Variable "instance" vom Typ SuperClass. Außerdem habe ich eine Klasse SubClass, die ich von SuperClass ableite. Handelt es sich nun bei der Variable "instance" von SuperClass um die selbe wie die von SubClass?

Mfg

Statische Variablen werden generell nicht vererbt. In subClass kann man zwar ohne Klassen-Qualifizierung
auf SuperClass.variable zugreifen, das ist aber schlechter Stil.
tfa

 

[Leroy42]

das ist aber schlechter Stil.tfa

Wieso das denn? Aus Sicht des Anwenders der Subklasse
braucht doch die Superklasse gar nicht zu interessieren. Noch
nicht einmal, ob es überhaupt eine Superklasse (außer Object) gibt.

Ich greife auf die statischen Members einer Klasse immer über
diese Klasse zu, egal ob diese nun in der Klasse selbst oder
einer ihrer Superklassen deklariert wurden.

Edit: Das heißt: Ich sehe es genau umgekehrt.

 

[Marco13]

Es ist bei statischen Variablen und Methoden imho sinnvoll (und "guter Stil" :wink: ) wenn man IMMER mit Klassen-Qualifizierung darauf zugreift - selbst innerhalb der deklarierenden Klasse. Dann sieht man sofort, dass es um "etwas statisches" geht.

 

[tfa]

das ist aber schlechter Stil.tfa

Wieso das denn? Aus Sicht des Anwenders der Subklasse
braucht doch die Superklasse gar nicht zu interessieren. Noch
nicht einmal, ob es überhaupt eine Superklasse (außer Object) gibt.

Ich greife auf die statischen Members einer Klasse immer über
diese Klasse zu, egal ob diese nun in der Klasse selbst oder
einer ihrer Superklassen deklariert wurden.

Tust Du nicht! "Statische Member" einer Klasse werden immer in der Klasse
selbst definiert und nicht in der Superklasse. Du greifst auf das Member der Oberklasse zu.
Die Betonung liegt auf statische.
Nochmal: Statische Variablen/Methoden werden nicht vererbt.
Ein Zugriff ohne Klassenqualifizierung (oder gar über ein Objekt) führt zu bösen
Überraschungen, wenn man diese Eigenheit nicht verinnerlicht hat.

Kleines Beispiel:

public class Vererbung {

    static class A {        
        public static String text() { return "A"; } 
    }
    
    static class B extends A {
        public static String text() { return "B"; }
    }
    
    public static void main(String[] args) {       
        A a = new A();
        B b = new B();
        System.out.println(a.text());
        System.out.println(b.text());
        
        a = b;
        System.out.println(a.text());        
    }    
}

Was wird ausgegeben?
Was wird ausgegeben, wenn man die "static" vor den Methodendefinitionen weglässt?

Bei uns im Projekt sind die IDEs so konfiguriert, dass nicht-qualifizierte Zugriffe auf
statische Member als Fehler angekreidet werden.

tfa

 

[Leroy42]

Sicher, ich meinte eher so etwas wie.

(Edit: Das bezog sich auf Marco13's Post)

public class MyFrame extends JFrame {
  public MyFrame() {
    ...
    setDefaultCloseOperation(EXIT_ON_CLOSE);
  }
  ...
}

Würdest du

1) EXIT_ON_CLOSE
2) MyFrame.EXIT_ON_CLOSE oder
3) JFrame.EXIT_ON_CLOSE

übergeben?

Ich selbst nutze dann immer Variante 1.
Ich widerspreche mir damit selbst (müßte
eigentlich 2) nehmen) , aber ich denke,
daß die Großbuchstaben bereits ein hinreichender
Hinweis auf die static-Eigenschaft von
EXIT_ON_CLOSE ist. ???:L

 

[tfa]

Sicher, ich meinte eher so etwas wie.

(Edit: Das bezog sich auf Marco13's Post)

public class MyFrame extends JFrame {
  public MyFrame() {
    ...
    setDefaultCloseOperation(EXIT_ON_CLOSE);
  }
  ...
}

Würdest du

1) EXIT_ON_CLOSE
2) MyFrame.EXIT_ON_CLOSE oder
3) JFrame.EXIT_ON_CLOSE

übergeben?

Ich selbst nutze dann immer Variante 1.
Ich widerspreche mir damit selbst (müßte
eigentlich 2) nehmen) , aber ich denke,
daß die Großbuchstaben bereits ein hinreichender
Hinweis auf die static-Eigenschaft von
EXIT_ON_CLOSE ist. ???:L

Ich würde 3) nehmen. EXIT_ON_CLOSE ist in JFrame definiert.
Dummerweise wird es auch im WindowConstants-Interface definiert,
welches durch JFrame implementiert wird. Solche Anti-Pattern gibt
es in Swing leider häufig. Pfui, Sun!

tfa

PS: Großbuchstaben beweisen leider gar nichts.

 

[Leroy42]

führt zu bösen Überraschungen, wenn man diese Eigenheit nicht verinnerlicht hat.

Eben! 😎

Pfui, Sun!

:applaus:

Großbuchstaben beweisen leider gar nichts.

Stimmt auch wieder. :shock:

 

[Marco13]

Würdest du

1) EXIT_ON_CLOSE
2) MyFrame.EXIT_ON_CLOSE oder
3) JFrame.EXIT_ON_CLOSE

übergeben?

Ich bin für 3: JFrame.EXIT_ON_CLOSE. Alles andere finde ich (ganz persönlich und subjektiv) SEHR unschön. "EXIT_ON_CLOSE" is tnun so "prominent", dass jeder weiß, wo es liegt (Äh - in JFrame und in WindowConstants - ja, das ist AUCH unschön....). Aber im Allgemeinen sollte man imho deutlich machen, dass es sich dabei um eine statische Variable handelt, und zu welcher Klasse sie gehört.

 

[Wildcard]

Gerade bei Konstanten muss man auch nicht übertreiben.
Wenn jemand wissen möchte was in der Konstanten steht, was macht er dann?
Strg drücken -> draufklicken -> in der richtigen Klasse rauskommen.
Wir programmieren schließlich nicht mehr mit VI... :wink:

 

[Marco13]

Ja, und Kommentare braucht man auch nicht, schließlich kann man ja den Code lesen :bae: :wink:

 

[Wildcard]

Ja, und Kommentare braucht man auch nicht, schließlich kann man ja den Code lesen :bae: :wink:

Mir ist die Problematik durchaus bewußt, aber gerade diese Swing Konstanten...
Ich möchte einem Label Formatierungen setzen.
Ist es wirkich praktikabel jedesmal nachzuschauen in welcher Klasse die entsprechende Konstante ursprünglich definiert wurde, oder ist es ganz natürlich JLabel.setBlahBlah(JLabel.BLAH_BLAH_CONSTANT) aufzurufen?
Ist das nicht sogar am besten lesbar?

 

[Marco13]

Ja, JLabel.RIGHT ist ja auch OK, obwohl es SwingConstants.RIGHT heißen """müßte""", aber garkeine Qualifizierung davorzuschreiben (in abgeleiteten Klassen) oder sogar ein Objekt zu verwenden finde ich etwas verwirrend und nicht sinnvoll. Ganz pragmatisch: Es spricht bei
jLabel.setBlah(jLabel.RIGHT);
ja nichts dagegen, das zweite 'j' groß zu schreiben 😀

 

[Wildcard]

Ja, JLabel.RIGHT ist ja auch OK, obwohl es SwingConstants.RIGHT heißen """müßte""", aber garkeine Qualifizierung davorzuschreiben

Klassenname davor schreiben sollte schon sein, nur muss es IMO nicht der sein in dem die Konstante tatsächlich definiert wurde, weil mich eben nicht interessiert ob die Konstante jetzt in JLabel, JComponent oder Component definiert ist.
Eine Ausnahme muss ich mir allerdings eingestehen, seltsamerweise schreibe ich immer

setDefaultCloseOperation(EXIT_ON_CLOSE);

???:L :bahnhof:

 

[Saxony]

Hiho,

seit 1.5. kann man diese Unart auch auf nicht "verwandte" Klassen ausweiten.

Stichwort: static import

Das Grauen hat einen weiteren Verbündeten. 😀

bye Saxony