Verständnisfrage - nested static classes

[jollyroger]

Hi,

kann mir bitte mal jemand erklären, warum um alles in der Welt ich jemals "nested static classes" einsetzen wollte?

Um mal kurz zu definieren was ich meine:

static classes: no associated outer class instance.

Das ist von hier:

-> http://mindprod.com/jgloss/nestedclasses.html

So eine "nested static class" würde z.b. so aussehen:

package com.mindprod.practice;

import com.mindprod.common11;

public class Outer
   {
   void anOuterMethod()
      {
      /* does nothing */
      }

   // static class, nested inside Outer
   public static class NestedStatic
      {
      void aNestedStaticMethod()
         {
         /* does nothing */
         }
      // end of class NestedStatic
      }

   // end of class Outer
   }

Sprich, es handelt sich um eine "inner class", nur das ich keine äußere Klasse brauche, um das Ding zu instanziieren.

Auf den ersten Blick betrachtet, kommt mir das wie das unsinnigste Sprachfeature überhaupt vor.

Wieso sollte ich sowas jemals machen?

Gibt es hier einen "realitätsnahen" Anwendungsfall?

 

[Marco13]

:shock: ja sicher - immer, wenn man eine "Hilfs-Klasse" braucht, die alleine exisitieren kann und soll - konkretes Beispiel aus einer der Map-Implementierungen

    /**
     * LinkedHashMap entry.
     */
    private static class Entry<K,V> extends HashMap.Entry<K,V> {
...

 

[jollyroger]

sicher - immer, wenn man eine "Hilfs-Klasse" braucht, die alleine exisitieren kann und soll

Und was spricht dann dagegen, eine "normale" Top-Level-Klasse daraus zu machen?

Anders gefragt: Was für einen Vorteil hat dein obiges Beispiel im Vergleich zu einer Top-Level Klasse?

Code-Übersichtlichkeit und Wartbarkeit kann es ja wohl nicht sein......und nur weil Sun das macht, muss ja noch lange nicht sinnvoll sein, weil das wäre eine Begründung nach dem Motto "Ich tue etwas und deshalb ist es sinnvoll".

P.S.: Nur um das nochmal klarzustellen: Es geht mir nicht um die Sinnhaftigkeit von "nested inner classes", sondern ausschließlich um die Sinnhaftigkeit von "nested static classes".

 

[musiKk]

Also soweit ich das verstanden habe, gibt es wirklich keinen Grund, nested static classes ausser zu Strukturierungszwecken einzusetzen. Was gegen Uebersichtlichkeit spricht, verstehe ich allerdings nicht. Es ist halt eine Ebene unter den Packages und drueckt noch eine gewisse Zugehoerigkeit aus.

 

[Marco13]

Und was spricht dann dagegen, eine "normale" Top-Level-Klasse daraus zu machen?

Nichts - abgesehen von verlorener "packaging convenience", bezug nehmend auf http://java.sun.com/docs/books/tutorial/java/javaOO/nested.html :wink:

 

[didjitalist]

Ein Aspekt von OO ist Kapselung. Es sollte nur das sichtbar sein, was für den Betrachter von Interesse ist. Nested classes können in ihrer Sichtbarkeit soweit eingeschränkt werden, dass sie nur noch für eine Klasse sichtbar sind und das kann sehr sinnvoll sein.

Es gibt übrigens sogar einen coding Grundsatz der besagt, dass inner classes immer static sein sollten, es sei denn, es gibt wirklich trifftige Gründe, die dagegen sprechen.

 

[musiKk]

Das heisst, wenn man deine beiden Aussagen zusammenfasst, soll man am besten private static bei inneren Klassen benutzen?

 

[Marco13]

Ganz subjektiv(!) würde ich sogar sagen, dass static classes meistens private sein sollten - wenn sie public sind, hat man ja wieder eine (ggf. unerwünschte) Verbindung zur einschließenden Klasse, wenn jemand eigentlich nur die innere Klasse verwenden will....

 

[musiKk]

Nur den Namen, das wuerde ich subjektiv(!) nicht als "Verbindung" sehen.

 

[jollyroger]

Ein Aspekt von OO ist Kapselung. Es sollte nur das sichtbar sein, was für den Betrachter von Interesse ist. Nested classes können in ihrer Sichtbarkeit soweit eingeschränkt werden, dass sie nur noch für eine Klasse sichtbar sind und das kann sehr sinnvoll sein.

Dann lies doch bitte mein Posting richtig.

Das "Nested Inner Classes" sehr sinnvoll sein können hab ich nie bestritten.

Darum hatte ich extra noch mal das hier

P.S.: Nur um das nochmal klarzustellen: Es geht mir nicht um die Sinnhaftigkeit von "nested inner classes", sondern ausschließlich um die Sinnhaftigkeit von "nested static classes".

angefügt.

Nochmal:

Static Nested Classes
As with class methods and variables, a static nested class is associated with its outer class. And like static class methods, a static nested class cannot refer directly to instance variables or methods defined in its enclosing class — it can use them only through an object reference.

Note: A static nested class interacts with the instance members of its outer class (and other classes) just like any other top-level class. In effect, a static nested class is behaviorally a top-level class that has been nested in another top-level class for packaging convenience.

Ok, eine nested static classes ist also

* eine Top-Level Class
* Hat genau die gleiche Sichtbarkeit als wenn ich sie in einem separaten source-file hätte
* Und kann im Prinzip von jedem aufgerufen werden -> im Unterschied zu "nested inner class" - da ist also nix mit erhöhter Kapselung!

Sprich,

ob ich das nun separat definiere oder als "static nested class" ist von den Auswirkungen her völlig egal, weil es aufs gleiche rauskommt?

Wo ist denn nun der Vorteil in welcher Situation?

Wenn das einzige Argument jetzt "bessere Lesbarkeit" ist, dann muss ich sagen -> das ist persönliche Ansichtssache.

Ich finde das eben nicht lesbarer, ein anderer vielleicht schon.

P.S.:

Falls ich was falsch verstanden haben sollte, bitte ich demutsvoll um Aufklärung..... :wink:

 

[maki]

Comperatoren sind gute Beispiele für statische innere Klassen, man braucht keine Instanzen, trennt aber dennoch die Aspekte und hält Dinge zusammen die irgendwie doch zusammengehören.

 

[jollyroger]

Um jetzt auch noch mal meinen Senf dazu zu geben, hab ich jetzt vor kurzem Code geschrieben, wo ich eine sinnvolle Anwendung für "nested static classes" gefunden habe, in Anlehnung an das was Maki geschrieben hatte:

Comperatoren sind gute Beispiele für statische innere Klassen, man braucht keine Instanzen, trennt aber dennoch die Aspekte und hält Dinge zusammen die irgendwie doch zusammengehören.

In meinem Fall war das ein DTO welches mehrere Comparatoren hatte. Eingesetzt wurde das ganze dann ungefähr folgendermaßen:

Arrays.sort(myDtoArr, new myDTO.myComparator());

Wie maki schon erwähnte ein sehr gutes Beispiel:

- myComparator macht nur im Context des DTOs Sinn
- soll aber unabhängig von einer konkreten Instanz des DTOs erzeugt werden

Wieder was gelernt, danke an alle........ :wink: