Perché un'interfaccia nidificata statica dovrebbe essere utilizzata in Java?

Ho appena trovato un'interfaccia nidificata statica nella nostra base di codice.

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

Non l'ho mai visto prima. Lo sviluppatore originale è fuori portata. Pertanto devo chiedere SO:

Quali sono le semantiche dietro un'interfaccia statica? Cosa cambierebbe se rimuovessi static? Perché qualcuno dovrebbe farlo?

La parola chiave statica nell'esempio sopra è ridondante (un'interfaccia nidificata è automaticamente "statica") e può essere rimossa senza alcun effetto sulla semantica; Consiglierei di essere rimosso. Lo stesso vale per "pubblico" sui metodi di interfaccia e "pubblico finale" sui campi di interfaccia: i modificatori sono ridondanti e aggiungono solo disordine al codice sorgente.

Ad ogni modo, lo sviluppatore sta semplicemente dichiarando un'interfaccia chiamata Foo.Bar. Non esiste alcuna ulteriore associazione con la classe che lo racchiude, ad eccezione del fatto che il codice che non può accedere a Foo non sarà in grado di accedere a Foo.Bar. (Dal codice sorgente - bytecode o reflection può accedere a Foo.Bar anche se Foo è un pacchetto privato!)

È accettabile creare un'interfaccia nidificata in questo modo se si prevede che venga utilizzata solo dalla classe esterna, in modo da non creare un nuovo nome di livello superiore. Per esempio:

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

Alla domanda è stata data una risposta, ma un buon motivo per usare un'interfaccia nidificata è se la sua funzione è direttamente correlata alla classe in cui si trova. Un buon esempio di questo è a Listener. Se tu avessi una classe Fooe volessi che altre classi potessero ascoltare eventi su di essa, potresti dichiarare un'interfaccia chiamata FooListener, il che è ok, ma probabilmente sarebbe più chiaro dichiarare un'interfaccia nidificata e far implementare quelle altre classi Foo.Listener( una classe nidificata Foo.Eventnon è male insieme a questo).

Le interfacce dei membri sono implicitamente statiche. Il modificatore statico nel tuo esempio può essere rimosso senza cambiare la semantica del codice. Vedi anche la specifica del linguaggio Java 8.5.1. Dichiarazioni sul tipo di membro statico

Un'interfaccia interna deve essere statica per poter accedere. L'interfaccia non è associata alle istanze della classe, ma alla classe stessa, quindi vi si accederà Foo.Bar, in questo modo:

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

Nella maggior parte dei modi, questo non è diverso da una classe interna statica.

La risposta di Jesse è vicina, ma penso che ci sia un codice migliore per dimostrare perché un'interfaccia interna può essere utile. Guarda il codice qui sotto prima di continuare a leggere. Riesci a capire perché l'interfaccia interna è utile? La risposta è che la classe DoSomethingAl già può essere istanziata con un'interfaccia interna che consente la costruzione di tipi personalizzati e ne migliora l'incapsulamento . qualsiasi classe che implementa A e C; non solo lo zoo di classe concreto. Naturalmente, questo può essere ottenuto anche se AC non è interno, ma immagina di concatenare nomi più lunghi (non solo A e C), e farlo per altre combinazioni (diciamo, A e B, C e B, ecc.) E tu facilmente guarda come le cose vanno fuori controllo. Per non parlare del fatto che le persone che recensiscono il tuo albero dei sorgenti saranno sopraffatte da interfacce significative solo in una classe. Quindi, per riassumere,

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;
  }
}

Per rispondere alla tua domanda in modo molto diretto, guarda Map.Entry.

Map.Entry

anche questo può essere utile

Voce del blog Static Nested Inerfaces

In genere vedo classi interne statiche. Le classi interne statiche non possono fare riferimento alle classi contenenti dove possono le classi non statiche. A meno che tu non stia incontrando alcune collisioni di pacchetti (esiste già un'interfaccia chiamata Bar nello stesso pacchetto di Foo), penso che lo farei diventare un suo file. Potrebbe anche essere una decisione progettuale far valere la connessione logica tra Foo e Bar. Forse l'autore voleva che Bar venisse usato solo con Foo (sebbene un'interfaccia interna statica non lo imponga, solo una connessione logica)

Se cambi la classe Foo nell'interfaccia Foo, anche la parola chiave "pubblica" nell'esempio sopra sarà ridondante perché

l'interfaccia definita all'interno di un'altra interfaccia sarà implicitamente pubblica statica.

Nel 1998, Philip Wadler ha suggerito una differenza tra interfacce statiche e interfacce non statiche.

Per quanto posso vedere, l'unica differenza nel rendere un'interfaccia non statica è che ora può includere classi interne non statiche; quindi la modifica non renderebbe non validi i programmi Java esistenti.

Ad esempio, ha proposto una soluzione al Problema di espressione , che è la discrepanza tra espressione come "quanto può esprimere la tua lingua" da un lato ed espressione come "i termini che stai cercando di rappresentare nella tua lingua" dall'altro .

Un esempio della differenza tra interfacce nidificate statiche e non statiche può essere visto nel suo codice di esempio :

// 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);
    }
}

Il suo suggerimento non è mai stato realizzato in Java 1.5.0. Pertanto, tutte le altre risposte sono corrette: non vi è alcuna differenza tra le interfacce nidificate statiche e non statiche.

In Java, l'interfaccia / classe statica consente all'interfaccia / classe di essere utilizzata come una classe di livello superiore, ovvero può essere dichiarata da altre classi. Quindi, puoi fare:

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

Senza lo statico, quanto sopra non sarebbe in grado di compilare. Il vantaggio è che non è necessario un nuovo file di origine solo per dichiarare l'interfaccia. Associa inoltre visivamente l'interfaccia Bar alla classe Foo poiché devi scrivere Foo.Bar e implica che la classe Foo fa qualcosa con le istanze di Foo.Bar.

Una descrizione dei tipi di classe in Java .

Statico significa che qualsiasi parte della classe del pacchetto (progetto) può accedervi senza usare un puntatore. Questo può essere utile o difficile a seconda della situazione.

L'esempio perfetto dell'utilità dei metodi "statici" è la classe di matematica. Tutti i metodi in matematica sono statici. Ciò significa che non devi fare nulla, creare una nuova istanza, dichiarare le variabili e archiviarle in ancora più variabili, puoi semplicemente inserire i tuoi dati e ottenere un risultato.

L'elettricità statica non è sempre così utile. Se, ad esempio, stai eseguendo un confronto tra casi, potresti voler archiviare i dati in diversi modi. Non è possibile creare tre metodi statici con firme identiche. Sono necessarie 3 diverse istanze, non statiche, quindi è possibile e confrontare, poiché se sono statiche, i dati non cambieranno insieme all'input.

I metodi statici sono utili per i rendimenti di una volta e per i calcoli rapidi o i dati facilmente ottenibili.