Warum sollte in Java eine statisch verschachtelte Schnittstelle verwendet werden?

Ich habe gerade eine statisch verschachtelte Schnittstelle in unserer Codebasis gefunden.

class Foo {
    public static interface Bar {
        /* snip */
    }
    /* snip */
}

Ich habe das noch nie gesehen. Der ursprüngliche Entwickler ist unerreichbar. Deshalb muss ich SO fragen:

Welche Semantik steckt hinter einer statischen Schnittstelle? Was würde sich ändern, wenn ich das entferne static? Warum sollte jemand das tun?

Das statische Schlüsselwort im obigen Beispiel ist redundant (eine verschachtelte Schnittstelle ist automatisch "statisch") und kann ohne Auswirkung auf die Semantik entfernt werden. Ich würde empfehlen, es zu entfernen. Gleiches gilt für "public" für Schnittstellenmethoden und "public final" für Schnittstellenfelder - die Modifikatoren sind redundant und fügen dem Quellcode nur Unordnung hinzu.

In beiden Fällen deklariert der Entwickler einfach eine Schnittstelle mit dem Namen Foo.Bar. Es gibt keine weitere Zuordnung zur einschließenden Klasse, außer dass der Code, der nicht auf Foo zugreifen kann, auch nicht auf Foo.Bar zugreifen kann. (Vom Quellcode - Bytecode oder Reflection können auf Foo.Bar zugreifen, auch wenn Foo paketprivat ist!)

Es ist akzeptabel, eine verschachtelte Schnittstelle auf diese Weise zu erstellen, wenn Sie erwarten, dass sie nur von der äußeren Klasse verwendet wird, damit Sie keinen neuen Namen der obersten Ebene erstellen. Beispielsweise:

public class Foo {
    public interface Bar {
        void callback();
    }
    public static void registerCallback(Bar bar) {...}
}
// ...elsewhere...
Foo.registerCallback(new Foo.Bar() {
    public void callback() {...}
});

Die Frage wurde beantwortet, aber ein guter Grund für die Verwendung einer verschachtelten Schnittstelle ist, dass ihre Funktion in direktem Zusammenhang mit der Klasse steht, in der sie sich befindet. Ein gutes Beispiel hierfür ist a Listener. Wenn Sie eine Klasse hatten Foound wollten, dass andere Klassen auf Ereignisse warten können, könnten Sie eine Schnittstelle mit dem Namen deklarieren FooListener, was in Ordnung ist, aber es wäre wahrscheinlich klarer, eine verschachtelte Schnittstelle zu deklarieren und diese anderen Klassen implementieren zu lassen Foo.Listener( eine verschachtelte Klasse Foo.Eventist damit nicht schlecht).

Mitgliedsschnittstellen sind implizit statisch. Der statische Modifikator in Ihrem Beispiel kann entfernt werden, ohne die Semantik des Codes zu ändern. Siehe auch die Java-Sprachspezifikation 8.5.1. Statische Elementtypdeklarationen

Eine innere Schnittstelle muss statisch sein, um darauf zugreifen zu können. Die Schnittstelle ist nicht mit Instanzen der Klasse verknüpft, sondern mit der Klasse selbst, sodass auf sie Foo.Barwie folgt zugegriffen werden kann:

public class Baz implements Foo.Bar {
   ...
}

In den meisten Fällen unterscheidet sich dies nicht von einer statischen inneren Klasse.

Jesses Antwort ist nah, aber ich denke, dass es einen besseren Code gibt, um zu demonstrieren, warum eine innere Schnittstelle nützlich sein kann. Schauen Sie sich den folgenden Code an, bevor Sie weiterlesen. Können Sie herausfinden, warum die innere Schnittstelle nützlich ist? Die Antwort ist, dass die Klasse DoSomethingAlready mit instanziiert werden kann, jeder Klasse kann , die A und C implementiert. nicht nur die konkrete Klasse Zoo. Dies kann natürlich auch erreicht werden, wenn AC nicht innerlich ist, aber stellen Sie sich vor, Sie verketten längere Namen (nicht nur A und C) und tun dies für andere Kombinationen (z. B. A und B, C und B usw.) und Sie leicht sehen, wie die Dinge außer Kontrolle geraten. Ganz zu schweigen davon, dass Personen, die Ihren Quellbaum überprüfen, von Schnittstellen überwältigt werden, die nur in einer Klasse von Bedeutung sind.Eine innere Schnittstelle ermöglicht die Erstellung benutzerdefinierter Typen und verbessert deren Kapselung .

class ConcreteA implements A {
 :
}

class ConcreteB implements B {
 :
}

class ConcreteC implements C {
 :
}

class Zoo implements A, C {
 :
}

class DoSomethingAlready {
  interface AC extends A, C { }

  private final AC ac;

  DoSomethingAlready(AC ac) {
    this.ac = ac;
  }
}

Um Ihre Frage sehr direkt zu beantworten, schauen Sie sich Map.Entry an.

Map.Entry

Auch dies kann nützlich sein

Blogeintrag für statisch verschachtelte Inerfaces

Normalerweise sehe ich statische innere Klassen. Statische innere Klassen können nicht auf die enthaltenen Klassen verweisen, wohingegen nicht statische Klassen dies können. Es sei denn, Sie stoßen auf Paketkollisionen (es gibt bereits eine Schnittstelle namens Bar im selben Paket wie Foo). Ich denke, ich würde es zu einer eigenen Datei machen. Es könnte auch eine Entwurfsentscheidung sein, die logische Verbindung zwischen Foo und Bar durchzusetzen. Vielleicht wollte der Autor, dass Bar nur mit Foo verwendet wird (obwohl eine statische innere Schnittstelle dies nicht erzwingt, sondern nur eine logische Verbindung).

Wenn Sie die Klasse Foo in die Schnittstelle Foo ändern, ist das Schlüsselwort "public" im obigen Beispiel ebenfalls redundant, da

Die in einer anderen Schnittstelle definierte Schnittstelle ist implizit öffentlich statisch.

1998 schlug Philip Wadler einen Unterschied zwischen statischen und nicht statischen Schnittstellen vor.

Soweit ich sehen kann, besteht der einzige Unterschied darin, eine Schnittstelle nicht statisch zu machen, darin, dass sie jetzt nicht statische innere Klassen enthalten kann. Die Änderung würde also keine vorhandenen Java-Programme ungültig machen.

Zum Beispiel schlug er eine Lösung für das Ausdrucksproblem vor , bei der es sich um die Nichtübereinstimmung zwischen dem Ausdruck "wie viel kann Ihre Sprache ausdrücken" einerseits und dem Ausdruck "die Begriffe, die Sie in Ihrer Sprache darstellen möchten" andererseits handelt .

Ein Beispiel für den Unterschied zwischen statischen und nicht statischen verschachtelten Schnittstellen ist in seinem Beispielcode zu sehen :

// This code does NOT compile
class LangF<This extends LangF<This>> {
    interface Visitor<R> {
        public R forNum(int n);
    }

    interface Exp {
        // since Exp is non-static, it can refer to the type bound to This
        public <R> R visit(This.Visitor<R> v);
    }
}

Sein Vorschlag hat es in Java 1.5.0 nie geschafft. Daher sind alle anderen Antworten richtig: Es gibt keinen Unterschied zu statischen und nicht statischen verschachtelten Schnittstellen.

In Java ermöglicht die statische Schnittstelle / Klasse, dass die Schnittstelle / Klasse wie eine Klasse der obersten Ebene verwendet wird, dh von anderen Klassen deklariert werden kann. Sie können also Folgendes tun:

class Bob
{
  void FuncA ()
  {
    Foo.Bar foobar;
  }
}

Ohne die statische Aufladung würde das oben Gesagte nicht kompiliert werden können. Dies hat den Vorteil, dass Sie keine neue Quelldatei benötigen, um die Schnittstelle zu deklarieren. Es ordnet die Schnittstellenleiste auch visuell der Klasse Foo zu, da Sie Foo.Bar schreiben müssen, und impliziert, dass die Foo-Klasse etwas mit Instanzen von Foo.Bar tut.

Eine Beschreibung der Klassentypen in Java .

Statisch bedeutet, dass jeder Klassenteil des Pakets (Projekts) ohne Verwendung eines Zeigers darauf zugreifen kann. Dies kann je nach Situation nützlich oder hinderlich sein.

Das perfekte Beispiel für die Nützlichkeit "statischer" Methoden ist die Math-Klasse. Alle Methoden in Mathe sind statisch. Dies bedeutet, dass Sie nicht aus dem Weg gehen, eine neue Instanz erstellen, Variablen deklarieren und in noch mehr Variablen speichern müssen. Sie können einfach Ihre Daten eingeben und ein Ergebnis erhalten.

Statik ist nicht immer so nützlich. Wenn Sie beispielsweise einen Fallvergleich durchführen, möchten Sie Daten möglicherweise auf verschiedene Arten speichern. Sie können nicht drei statische Methoden mit identischen Signaturen erstellen. Sie benötigen 3 verschiedene Instanzen, nicht statisch, und dann können Sie vergleichen, denn wenn es statisch ist, ändern sich die Daten nicht zusammen mit der Eingabe.

Statische Methoden eignen sich für einmalige Rückgaben und schnelle Berechnungen oder einfach zu ermittelnde Daten.