innere Klassen zu äusseren Klassen machen

[Tron36]

Hallo Leute,

ich hab da eine allgemeine Frage zu inneren Klassen. Ich habe z.B. folgenden Code bzw. innere Klasse:

static class Table {
       Table Zeile(){
       ...
}

wenn ich es "auslagere" und daraus eine äussere Klasse mache, werden die Funktionen der Klasse statisch, wenn ich auch andere Funktionen habe? bzw. was passiert mit dem static?

Lg Tron36

 

[Rossie]

Nimm eine beliege IDE, die Refactoring kann und probier es aus!

 

[Tron36]

hab zwar gemacht, die frage ist ob die IDE immer so recht hat, was er macht.

 

[1668mib]

static bei einer inneren Klasse heißt nur, dass diese Klasse auch ohne eine Instanz der äußeren Klasse existieren kann und auch nicht an eine Instanz gebunden ist.

Beispiele:

class Outer {
  int a;
  class Inner {
    void foo() {
      a = 1; // geht
    }
  }

  static class Inner2 {
    void foo() {
      a = 1;  // geht nicht
    }
  }
}

class Other {
  void foo() {
    new Outer.Inner(); // geht nicht
    new Outer.Inner2(); // geht
  }
}

Mit statischen Elementen hat diese static-Eigenschaft nichts zu tun, sie beschreibt nur das Verhältnis von äußerer und innerer Klasse. Ohne static ist eine innere Klasse an den Kontext einer äußeren Klassen-Instanz gebunden, und hat auch alle Zugriffsmöglichkeiten auf Member der äußeren Klasse. Häufig sieht man das ja bei anonymen Klassen für Event-Handler.

Beispiel Event-Handler:

class MyGUI {
  MyGUI() {
    keyboard.addEventListener(new KeyboardListener());
  }

  void updateUI() { ... }

  class KeyboardListener implements IKeyEvent {
    void keyEvent(int code) {
      updateUI();
    }
  }
}

Die Klasse KeyboardListener "braucht" eine äußere Instanz von MyGUI - ohne MyGUI macht KeyboardListener keinen Sinn.
Natürlich gibt es auch andere Möglichkeiten, z.B. dem Listener die Referenz auf MyGUI explizit zu übergeben, dann könnte die Klasse auch statisch sein.

Eine nicht-statische innere Klasse ist immer an die äußere Klasse "gebunden", in der sie instantiiert wird.

die frage ist ob die IDE immer so recht hat, was er macht.

Ich glaube die IDEs wissen besser, was sie zu tun haben, als du.

 

[Rossie]

hab zwar gemacht, die frage ist ob die IDE immer so recht hat, was er macht.

Die entsprechende Refactoring-Aktion existiert seit 2003. Sollte abgehangen genug sein, um sicherzustellen, dass es fehlerfrei funktioniert

Es schadet sicherlich nicht, sich mit der Theorie zu beschäftigen. Ich würde zu Anfang immer ein Buch o.ä. durcharbeiten. Aber eine IDE wie Eclipse ist schon ein sehr mächtiges und hilfreiches Tool, mit dem man solchen Fragestellungen auch spielerisch begegnen kann.

 

[Tron36]

Die entsprechende Refactoring-Aktion existiert seit 2003. Sollte abgehangen genug sein, um sicherzustellen, dass es fehlerfrei funktioniert

Davon gehe auch aus. Die Sache ist, dass die Funktionen ohne Zugriffsmodifizierer erzeugt wurden.

Lg Tron36

 

[Rossie]

Die Sache ist, dass die Funktionen ohne Zugriffsmodifizierer erzeugt wurden.

Das Refactoring verschiebt lediglich die Klasse. Erzeugt wird hier nichts. Wenn Methoden eine andere Sichtbarkeit haben sollen, musst Du das händisch ändern. Entweder vor oder nach dem Refactoring.

 

[1668mib]

Davon gehe auch aus. Die Sache ist, dass die Funktionen ohne Zugriffsmodifizierer erzeugt wurden.

Ja und? Was sollte mit den Zugriffsmodifizierern denn passieren?

Ich glaube du hast immer noch nicht kapiert, was "statische innere Klasse" heißt... aber du kannst mich ja gerne vom Gegenteil überzeugen.