Définition de Java Enum

Je pensais comprendre assez bien les génériques Java, mais je suis ensuite tombé sur ce qui suit dans java.lang.Enum:

class Enum<E extends Enum<E>>

Quelqu'un pourrait-il expliquer comment interpréter ce paramètre de type? Des points bonus pour fournir d'autres exemples d'utilisation d'un paramètre de type similaire.

Cela signifie que l'argument de type pour enum doit dériver d'un enum qui a lui-même le même argument de type. Comment cela peut-il arriver? En faisant de l'argument de type le nouveau type lui-même. Donc, si j'ai une énumération appelée StatusCode, ce serait équivalent à:

public class StatusCode extends Enum<StatusCode>

Maintenant, si vous vérifiez les contraintes, nous avons Enum<StatusCode>- donc E=StatusCode. Vérifions: Es'étend-il Enum<StatusCode>? Oui! Nous allons bien.

Vous vous demandez peut-être à quoi cela sert :) Eh bien, cela signifie que l'API pour Enum peut se référer à elle-même - par exemple, être capable de dire qu'elle Enum<E>implémente Comparable<E>. La classe de base est capable de faire les comparaisons (dans le cas des énumérations) mais elle peut s'assurer qu'elle compare uniquement le bon type d'énumérations entre elles. (EDIT: Eh bien, presque - voir la modification en bas.)

J'ai utilisé quelque chose de similaire dans mon port C # de ProtocolBuffers. Il existe des «messages» (immuables) et des «générateurs» (mutables, utilisés pour construire un message) - et ils se présentent sous la forme de paires de types. Les interfaces concernées sont:

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>

Cela signifie qu'à partir d'un message, vous pouvez obtenir un constructeur approprié (par exemple pour prendre une copie d'un message et modifier certains bits) et d'un constructeur, vous pouvez obtenir un message approprié lorsque vous avez fini de le construire. C'est un bon travail que les utilisateurs de l'API n'ont pas besoin de se soucier de cela - c'est horriblement compliqué et il a fallu plusieurs itérations pour en arriver là.

EDIT: Notez que cela ne vous empêche pas de créer des types impairs qui utilisent un argument de type qui lui-même est correct, mais qui n'est pas du même type. Le but est de donner des avantages dans le bon cas plutôt que de vous protéger du mauvais cas.

Donc, si Enumvous n'avez pas été manipulé "spécialement" en Java de toute façon, vous pouvez (comme indiqué dans les commentaires) créer les types suivants:

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

Secondmettrait en œuvre Comparable<First>plutôt que Comparable<Second>... mais Firstlui-même serait très bien.

Ce qui suit est une version modifiée de l'explication du livre Java Generics and Collections : Nous avons Enumdéclaré

enum Season { WINTER, SPRING, SUMMER, FALL }

qui sera étendu à une classe

final class Season extends ...

où ...doit être la classe de base paramétrée pour Enums. Voyons ce que cela doit être. Eh bien, l'une des conditions requises Seasonest qu'elle doit être mise en œuvre Comparable<Season>. Donc nous allons avoir besoin

Season extends ... implements Comparable<Season>

Que pourriez-vous utiliser pour ...que cela fonctionne? Étant donné qu'il doit s'agir d'un paramétrage de Enum, le seul choix est Enum<Season>, de sorte que vous puissiez avoir:

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

Ainsi Enumest paramétré sur des types comme Season. Abstrait de Seasonet vous obtenez que le paramètre de Enumest n'importe quel type qui satisfait

 E extends Enum<E>

Maurice Naftalin (co-auteur, Java Generics and Collections)

Ceci peut être illustré par un exemple simple et une technique qui peut être utilisée pour implémenter des appels de méthode chaînée pour des sous-classes. Dans un exemple ci - dessous setNamerenvoie un Nodeenchaînant donc ne fonctionnera pas pour le 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
}

Nous pourrions donc référencer une sous-classe dans une déclaration générique, de sorte que le Cityrenvoie maintenant le type correct:

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

Vous n'êtes pas le seul à vous demander ce que cela signifie; voir le blog Chaotic Java .

«Si une classe étend cette classe, elle doit passer un paramètre E. Les limites du paramètre E sont pour une classe qui étend cette classe avec le même paramètre E».

Cet article m'a totalement clarifié le problème des «types génériques récursifs». Je voulais juste ajouter un autre cas où cette structure particulière est nécessaire.

Supposons que vous ayez des nœuds génériques dans un graphe générique:

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

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

    public Collection<T> getNeighbor();
}

Ensuite, vous pouvez avoir des graphiques de types spécialisés:

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

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

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

Si vous regardez le Enumcode source, il contient les éléments suivants:

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

Tout d'abord, qu'est-ce que E extends Enum<E> signifie? Cela signifie que le paramètre type est quelque chose qui s'étend à partir de Enum, et n'est pas paramétré avec un type brut (il est paramétré par lui-même).

Ceci est pertinent si vous avez une énumération

public enum MyEnum {
    THING1,
    THING2;
}

qui, si je sais bien, se traduit par

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

Cela signifie donc que MyEnum reçoit les méthodes suivantes:

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

Et plus important encore,

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

Cela rend le getDeclaringClass()casting au bonClass<T> objet .

Un exemple bien plus clair est celui auquel j'ai répondu sur cette question où vous ne pouvez pas éviter cette construction si vous souhaitez spécifier une borne générique.

Selon wikipedia, ce modèle est appelé modèle de modèle curieusement récurrent . Fondamentalement, en utilisant le modèle CRTP, nous pouvons facilement faire référence au type de sous-classe sans conversion de type, ce qui signifie qu'en utilisant le modèle, nous pouvons imiter la fonction virtuelle.