# Frage zu statischen Variablen bei Vererbung



## Guest (18. Mrz 2007)

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 (18. Mrz 2007)

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


----------



## tfa (19. Mrz 2007)

Anonymous hat gesagt.:
			
		

> 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 (19. Mrz 2007)

tfa hat gesagt.:
			
		

> 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 (19. Mrz 2007)

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 (19. Mrz 2007)

Leroy42 hat gesagt.:
			
		

> tfa hat gesagt.:
> 
> 
> 
> ...



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 (19. Mrz 2007)

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 (19. Mrz 2007)

Leroy42 hat gesagt.:
			
		

> Sicher, ich meinte eher so etwas wie.
> 
> (Edit: Das bezog sich auf Marco13's Post)
> 
> ...



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 (19. Mrz 2007)

tfa hat gesagt.:
			
		

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



Eben!   



			
				tfa hat gesagt.:
			
		

> Pfui, Sun!


 :applaus: 



			
				tfa hat gesagt.:
			
		

> Großbuchstaben beweisen leider gar nichts.



Stimmt auch wieder.  :shock:


----------



## Marco13 (19. Mrz 2007)

Leroy42 hat gesagt.:
			
		

> Würdest du
> 
> 1) EXIT_ON_CLOSE
> 2) MyFrame.EXIT_ON_CLOSE  oder
> ...


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 (19. Mrz 2007)

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 (19. Mrz 2007)

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


----------



## Wildcard (19. Mrz 2007)

Marco13 hat gesagt.:
			
		

> 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 (19. Mrz 2007)

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 (19. Mrz 2007)

Marco13 hat gesagt.:
			
		

> 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 (20. Mrz 2007)

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


----------

