Definizione di Java Enum

Pensavo di aver capito abbastanza bene i generici Java, ma poi mi sono imbattuto in java.lang.Enum:

class Enum<E extends Enum<E>>

Qualcuno potrebbe spiegare come interpretare questo parametro di tipo? Punti bonus per fornire altri esempi di dove potrebbe essere utilizzato un parametro di tipo simile.

Significa che l'argomento tipo per enum deve derivare da un enum che a sua volta ha lo stesso argomento tipo. Come può succedere? Rendendo l'argomento type il nuovo tipo stesso. Quindi, se ho un enum chiamato StatusCode, sarebbe equivalente a:

public class StatusCode extends Enum<StatusCode>

Ora, se controlli i vincoli, abbiamo Enum<StatusCode>- così E=StatusCode. Controlliamo: si Eestende Enum<StatusCode>? Sì! Stiamo bene

Potresti chiederti qual è il punto di questo :) Bene, significa che l'API per Enum può fare riferimento a se stessa - ad esempio, essere in grado di dire che Enum<E>implementa Comparable<E>. La classe base è in grado di fare i confronti (nel caso di enumerazioni) ma può assicurarsi che confronta solo il giusto tipo di enumerazioni tra loro. (EDIT: Beh, quasi - vedi la modifica in fondo.)

Ho usato qualcosa di simile nella mia porta C # di ProtocolBuffers. Ci sono "messaggi" (immutabili) e "costruttori" (mutabili, usati per costruire un messaggio) - e vengono come coppie di tipi. Le interfacce coinvolte sono:

public interface IBuilder<TMessage, TBuilder>
  where TMessage : IMessage<TMessage, TBuilder> 
  where TBuilder : IBuilder<TMessage, TBuilder>

public interface IMessage<TMessage, TBuilder>
  where TMessage : IMessage<TMessage, TBuilder> 
  where TBuilder : IBuilder<TMessage, TBuilder>

Ciò significa che da un messaggio è possibile ottenere un builder appropriato (ad es. Per prendere una copia di un messaggio e modificare alcuni bit) e da un builder è possibile ottenere un messaggio appropriato al termine della costruzione. È comunque un buon lavoro, gli utenti dell'API non devono preoccuparsene davvero - è terribilmente complicato e ha impiegato diverse iterazioni per arrivare dove si trova.

EDIT: Nota che questo non ti impedisce di creare tipi dispari che usano un argomento di tipo che va bene, ma che non è lo stesso tipo. Lo scopo è quello di dare benefici nel caso giusto piuttosto che proteggerti dal caso sbagliato .

Quindi se Enumnon sono stati gestiti "specialmente" in Java, è possibile (come indicato nei commenti) creare i seguenti tipi:

public class First extends Enum<First> {}
public class Second extends Enum<First> {}

Secondimplementerebbe Comparable<First>piuttosto che Comparable<Second>... ma Firstandrebbe bene.

La seguente è una versione modificata della spiegazione del libro Java Generics and Collections : ne abbiamo Enumdichiarato uno

enum Season { WINTER, SPRING, SUMMER, FALL }

che verrà espanso in una classe

final class Season extends ...

dove ...deve essere la classe base in qualche modo parametrizzata per Enums. Scopriamo cosa deve essere. Bene, uno dei requisiti Seasonè che dovrebbe implementare Comparable<Season>. Quindi avremo bisogno

Season extends ... implements Comparable<Season>

Cosa potresti usare per ...permettere a questo di funzionare? Dato che deve essere una parametrizzazione di Enum, l'unica scelta è Enum<Season>, in modo da poter avere:

Season extends Enum<Season>
Enum<Season> implements Comparable<Season>

Quindi Enumè parametrizzato su tipi come Season. Estratto da Seasone ottieni che il parametro di Enumè qualsiasi tipo che soddisfi

 E extends Enum<E>

Maurice Naftalin (coautore, Java Generics and Collections)

Ciò può essere illustrato da un semplice esempio e da una tecnica che può essere utilizzata per implementare chiamate di metodi concatenate per le sottoclassi. Nell'esempio seguente viene setNamerestituito un Nodeconcatenamento che non funziona per City:

class Node {
    String name;

    Node setName(String name) {
        this.name = name;
        return this;
    }
}

class City extends Node {
    int square;

    City setSquare(int square) {
        this.square = square;
        return this;
    }
}

public static void main(String[] args) {
    City city = new City()
        .setName("LA")
        .setSquare(100);    // won't compile, setName() returns Node
}

Quindi potremmo fare riferimento a una sottoclasse in una dichiarazione generica, in modo che Cityora restituisca il tipo corretto:

abstract class Node<SELF extends Node<SELF>>{
    String name;

    SELF setName(String name) {
        this.name = name;
        return self();
    }

    protected abstract SELF self();
}

class City extends Node<City> {
    int square;

    City setSquare(int square) {
        this.square = square;
        return self();
    }

    @Override
    protected City self() {
        return this;
    }

    public static void main(String[] args) {
       City city = new City()
            .setName("LA")
            .setSquare(100);                 // ok!
    }
}

Non sei il solo a chiederti cosa significhi; vedi il blog di Chaotic Java .

"Se una classe estende questa classe, dovrebbe passare un parametro E. I limiti del parametro E sono per una classe che estende questa classe con lo stesso parametro E".

Questo post mi ha chiarito totalmente questo problema di "tipi generici ricorsivi". Volevo solo aggiungere un altro caso in cui questa particolare struttura fosse necessaria.

Supponiamo di avere nodi generici in un grafico generico:

public abstract class Node<T extends Node<T>>
{
    public void addNeighbor(T);

    public void addNeighbors(Collection<? extends T> nodes);

    public Collection<T> getNeighbor();
}

Quindi puoi avere grafici di tipi specializzati:

public class City extends Node<City>
{
    public void addNeighbor(City){...}

    public void addNeighbors(Collection<? extends City> nodes){...}

    public Collection<City> getNeighbor(){...}
}

Se guardi il Enumcodice sorgente, ha il seguente:

public abstract class Enum<E extends Enum<E>>
        implements Comparable<E>, Serializable {

    public final int compareTo(E o) {
        Enum<?> other = (Enum<?>)o;
        Enum<E> self = this;
        if (self.getClass() != other.getClass() && // optimization
            self.getDeclaringClass() != other.getDeclaringClass())
            throw new ClassCastException();
        return self.ordinal - other.ordinal;
    }

    @SuppressWarnings("unchecked")
    public final Class<E> getDeclaringClass() {
        Class<?> clazz = getClass();
        Class<?> zuper = clazz.getSuperclass();
        return (zuper == Enum.class) ? (Class<E>)clazz : (Class<E>)zuper;
    }

    public static <T extends Enum<T>> T valueOf(Class<T> enumType,
                                                String name) {
        T result = enumType.enumConstantDirectory().get(name);
        if (result != null)
            return result;
        if (name == null)
            throw new NullPointerException("Name is null");
        throw new IllegalArgumentException(
            "No enum constant " + enumType.getCanonicalName() + "." + name);
    } 
}

Prima cosa, cosa E extends Enum<E>significa? Significa che il parametro type è qualcosa che si estende da Enum e non è parametrizzato con un tipo raw (è parametrizzato da solo).

Questo è rilevante se hai un enum

public enum MyEnum {
    THING1,
    THING2;
}

che, se lo so correttamente, è tradotto in

public final class MyEnum extends Enum<MyEnum> {
    public static final MyEnum THING1 = new MyEnum();
    public static final MyEnum THING2 = new MyEnum();
}

Ciò significa che MyEnum riceve i seguenti metodi:

public final int compareTo(MyEnum o) {
    Enum<?> other = (Enum<?>)o;
    Enum<MyEnum> self = this;
    if (self.getClass() != other.getClass() && // optimization
        self.getDeclaringClass() != other.getDeclaringClass())
        throw new ClassCastException();
    return self.ordinal - other.ordinal;
}

E ancora più importante,

    @SuppressWarnings("unchecked")
    public final Class<MyEnum> getDeclaringClass() {
        Class<?> clazz = getClass();
        Class<?> zuper = clazz.getSuperclass();
        return (zuper == Enum.class) ? (Class<MyEnum>)clazz : (Class<MyEnum>)zuper;
    }

Questo rende il getDeclaringClass()cast per l' Class<T>oggetto corretto .

Un esempio molto più chiaro è quello a cui ho risposto a questa domanda in cui non è possibile evitare questo costrutto se si desidera specificare un limite generico.

Secondo Wikipedia, questo modello è chiamato modello di modello curiosamente ricorrente . Fondamentalmente, usando il modello CRTP, possiamo facilmente fare riferimento al tipo di sottoclasse senza il tipo casting, il che significa che usando il modello, possiamo imitare la funzione virtuale.