Java-Enum-Definition

Ich dachte, ich hätte Java-Generika ziemlich gut verstanden, aber dann bin ich in java.lang.Enum auf Folgendes gestoßen:

class Enum<E extends Enum<E>>

Könnte jemand erklären, wie dieser Typparameter zu interpretieren ist? Bonuspunkte für die Bereitstellung anderer Beispiele dafür, wo ein ähnlicher Typparameter verwendet werden könnte.

Das bedeutet, dass das Typargument für Aufzählung von einer Aufzählung abgeleitet werden muss, die selbst das gleiche Typargument hat. Wie kann das passieren? Indem das Typargument zum neuen Typ selbst gemacht wird. Wenn ich also eine Aufzählung namens StatusCode habe, wäre dies äquivalent zu:

public class StatusCode extends Enum<StatusCode>

Wenn Sie jetzt die Einschränkungen überprüfen, haben wir Enum<StatusCode> – damit E=StatusCode. Lassen Sie uns überprüfen: tut E erweitern Enum<StatusCode>? Jawohl! Wir sind in Ordnung.

Sie fragen sich vielleicht, was das soll 🙂 Nun, es bedeutet, dass die API für Enum auf sich selbst verweisen kann – zum Beispiel in der Lage zu sein, das zu sagen Enum<E> implementiert Comparable<E>. Die Basisklasse kann die Vergleiche durchführen (im Fall von Aufzählungen), aber sie kann sicherstellen, dass sie nur die richtigen Arten von Aufzählungen miteinander vergleicht. (EDIT: Nun, fast – siehe die Bearbeitung unten.)

Ich habe etwas Ähnliches in meinem C#-Port von ProtocolBuffers verwendet. Es gibt „Messages“ (unveränderlich) und „Builder“ (veränderlich, um eine Nachricht zu erstellen) – und sie kommen als Typenpaare vor. Die beteiligten Schnittstellen sind:

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>

Das bedeutet, dass Sie von einer Nachricht einen geeigneten Builder erhalten können (z. B. um eine Kopie einer Nachricht zu nehmen und einige Bits zu ändern) und von einem Builder können Sie eine entsprechende Nachricht erhalten, wenn Sie mit dem Erstellen fertig sind. Es ist ein guter Job, dass Benutzer der API sich nicht wirklich darum kümmern müssen – es ist entsetzlich kompliziert und es dauerte mehrere Iterationen, um dorthin zu gelangen, wo es ist.

BEARBEITEN: Beachten Sie, dass dies Sie nicht davon abhält, ungerade Typen zu erstellen, die ein Typargument verwenden, das selbst in Ordnung ist, aber nicht vom gleichen Typ ist. Zweck ist die Gewährung von Vorteilen in der rechts Fall, anstatt Sie vor dem zu schützen falsch Fall.

Also wenn Enum wurden in Java sowieso nicht “speziell” behandelt, Sie könnten (wie in den Kommentaren erwähnt) die folgenden Typen erstellen:

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

Second umsetzen würde Comparable<First> eher, als Comparable<Second>… aber First selbst wäre in Ordnung.

Das Folgende ist eine modifizierte Version der Erklärung aus dem Buch Java-Generika und -Sammlungen: Wir haben ein Enum erklärt

enum Season { WINTER, SPRING, SUMMER, FALL }

die zu einer Klasse erweitert wird

final class Season extends ...

wo ... soll die irgendwie parametrisierte Basisklasse für Enums sein. Lassen Sie uns herausfinden, was das sein muss. Nun, eine der Voraussetzungen für Season ist, dass es implementieren sollte Comparable<Season>. Also werden wir brauchen

Season extends ... implements Comparable<Season>

Was könntest du gebrauchen ... damit würde das funktionieren? Da es sich um eine Parametrisierung von handeln muss Enumdie einzige Wahl ist Enum<Season>damit Sie Folgendes haben können:

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

Damit Enum ist auf Typen wie parametriert Season. Auszug aus Season und Sie erhalten, dass der Parameter von Enum ist jeder Typ, der erfüllt

 E extends Enum<E>

Maurice Naftalin (Co-Autor, Java Generics and Collections)

Dies kann durch ein einfaches Beispiel und eine Technik veranschaulicht werden, die verwendet werden kann, um verkettete Methodenaufrufe für Unterklassen zu implementieren. In einem Beispiel unten setName gibt a zurück Node Verkettung funktioniert also nicht für die 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
}

Wir könnten also in einer generischen Deklaration auf eine Unterklasse verweisen, sodass die City gibt jetzt den richtigen Typ zurück:

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

Sie sind nicht der Einzige, der sich fragt, was das bedeutet; sehen Chaotischer Java-Blog.

„Wenn eine Klasse diese Klasse erweitert, sollte sie einen Parameter E übergeben. Die Grenzen des Parameters E gelten für eine Klasse, die diese Klasse mit demselben Parameter E erweitert“.

Dieser Beitrag hat mir dieses Problem der “rekursiven generischen Typen” vollständig verdeutlicht. Ich wollte nur einen weiteren Fall hinzufügen, in dem diese besondere Struktur notwendig ist.

Angenommen, Sie haben generische Knoten in einem generischen Diagramm:

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

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

    public Collection<T> getNeighbor();
}

Dann können Sie Diagramme spezialisierter Typen haben:

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

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

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

Schaut man sich die an Enum Quellcode, es hat folgendes:

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

Das Wichtigste zuerst, was tut E extends Enum<E> bedeuten? Dies bedeutet, dass der Typparameter etwas ist, das sich von Enum aus erstreckt und nicht mit einem Rohtyp parametrisiert ist (er wird von selbst parametrisiert).

Dies ist relevant, wenn Sie eine Aufzählung haben

public enum MyEnum {
    THING1,
    THING2;
}

was, wenn ich es richtig weiß, übersetzt wird

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

Das bedeutet also, dass MyEnum die folgenden Methoden erhält:

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

Und noch wichtiger,

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

Das macht getDeclaringClass() zum richtigen werfen Class<T> Objekt.

Ein viel klareres Beispiel ist das, das ich auf diese Frage beantwortet habe, wo Sie dieses Konstrukt nicht vermeiden können, wenn Sie eine generische Grenze angeben möchten.

Laut Wikipedia heißt dieses Muster Seltsam wiederkehrendes Schablonenmuster. Grundsätzlich können wir durch die Verwendung des CRTP-Musters leicht auf den Unterklassentyp ohne Typumwandlung verweisen, was bedeutet, dass wir durch die Verwendung des Musters eine virtuelle Funktion imitieren können.