Gibt es eine Begründung für diese verschachtelten Schnittstellen?

Question

Ich habe einige Java-Code geerbt, das hat:

interface PairDeviceCallbacks extends BasePresenter { 
    interface View extends BaseView { 
    // declare some methods 
    } 
    void onDeviceClicked(...) 
} 

Class1 implements PairDeviceCallbacks und Class2 implements PairDeviceCallbacks.View. Ich verstehe nicht, warum es so strukturiert wurde, insbesondere warum die verschachtelte Schnittstelle. Warum nicht einfach zwei separate Top-Level-Schnittstellen? Gibt es einen Grund, diese Komplexität hinzuzufügen?

Answer 1

Soweit ich weiß, hat das Verschachteln von Schnittstellen zwei Vorteile. Erstens, dass es uns erlaubt, Interfaces zu gruppieren, die miteinander verwandt sind und auch in einer Art und Weise Encapsulation verbessert. Das heißt, wir können die verschachtelte Schnittstelle nur aufrufen, indem wir die äußere Schnittstelle oder die Klasse im selben Paket verwenden.

Answer 2

Eine Schnittstelle muss von jemand anderem implementiert werden. Daher wird es oft als Anforderungen(Parameterklasse) verwendet. Es könnte gut sein, dass die äußere Schnittstelle Dinge auf etwas der inneren Schnittstelle tun muss (Definieren der erforderlichen Methoden).

Wenn das für die äußere Klasse/Schnittstelle sehr spezifisch ist, könnte man es als verschachtelte Schnittstelle behalten.

Die andere Nutzung einer Schnittstelle ist Dienste geliefert (return Ergebnisse) angeben. Es könnte gut sein, dass die äußere Klasse eine Methode liefert, die ein sehr spezifisches Objekt liefert. Solch eine spezifische Schnittstelle kann auch verschachtelt werden.

Wie spezifisch solch eine Schnittstelle ist, bestimmt, ob die Schnittstelle das Recht hat, unabhängig zu sein. Innere Schnittstellen dienen als Liste der benötigten Anforderungen oder Liste der angebotenen Dienste.

---

(Phantasie-) Beispiel

interface ChangeListener { 
    interface ChangeEvent { 
     Object getSource(); // Requirement: required functionality. 
     Object getOldValue(); 
     Object getNewValue(); 
    } 
    void onChange(ChangeEvent event); // Service: served/provided functionality. 
} 

// A library creator may add handling of colors: 
public class ColorChangeEvent implements ChangeEvent { 
    ColorChangeEvent(Object source, Color color) { ... } 
    Object getSource() { ... } 
    Color getColor() { .... } 
} 

// An API user may only need to subclass ChangeListener: 
add(new ChangeListener() { ... }); 

Hier würde man fast erwarten Generika, oder ein ColorChangeListener. Schnittstellen wurden für verschiedene Klassenhierarchien verwendet.

---

Für Rückrufe heute lambdas erscheinen häufiger auch spezifische Schnittstellen ersetzt nur eine einzige Methode zu geben: Consumer<List<Good>> und so.

Verschachtelte Klassen haben noch andere Gründe. Eine nicht statische innere Klasse hat Zugriff auf die äußere Instanz. Betrachten Sie eine äußere Container-Klasse wie Book und innere Klassen wie Chapter, die somit Zugriff auf das Inhaltsverzeichnis des Buches und dergleichen haben.