Definicja Java Enum

Wydawało mi się, że całkiem dobrze rozumiem typy generyczne Javy, ale potem w java.lang.Enum natknąłem się na następujące rzeczy:

class Enum<E extends Enum<E>>

Czy ktoś mógłby wyjaśnić, jak interpretować ten parametr typu? Dodatkowe punkty za udostępnienie innych przykładów, w których można zastosować podobny parametr typu.

Oznacza to, że argument typu dla wyliczenia musi pochodzić z wyliczenia, które samo ma ten sam argument typu. Jak to się stało? Poprzez uczynienie argumentu type nowym typem. Więc jeśli mam wyliczenie o nazwie StatusCode, byłoby to równoważne z:

public class StatusCode extends Enum<StatusCode>

Teraz, jeśli sprawdzisz ograniczenia, mamy Enum<StatusCode>- więc E=StatusCode. Sprawdźmy: Erozszerza sięEnum<StatusCode> ? Tak! W porządku.

Możesz zadawać sobie pytanie, o co w tym wszystkim chodzi :) Cóż, oznacza to, że API dla Enum może odnosić się do siebie - na przykład, będąc w stanie powiedzieć, że Enum<E>implementuje Comparable<E>. Klasa bazowa jest w stanie dokonywać porównań (w przypadku wyliczeń), ale może upewnić się, że porównuje ze sobą tylko właściwy rodzaj wyliczeń. (EDYCJA: Cóż, prawie - zobacz edycję na dole.)

Użyłem czegoś podobnego w moim porcie C # ProtocolBuffers. Istnieją „wiadomości” (niezmienne) i „konstruktorzy” (zmienne, używane do tworzenia wiadomości) - i występują jako pary typów. Stosowane interfejsy to:

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>

Oznacza to, że z wiadomości możesz uzyskać odpowiedni konstruktor (np. Aby skopiować wiadomość i zmienić kilka bitów), a od konstruktora możesz otrzymać odpowiednią wiadomość, gdy skończysz ją budować. To dobra robota, ale użytkownicy API nie muszą się tym przejmować - jest to horrendalnie skomplikowane i wymagało kilku iteracji, aby dostać się tam, gdzie jest.

EDYCJA: Zauważ, że nie powstrzymuje cię to przed tworzeniem dziwnych typów, które używają argumentu typu, który sam w sobie jest w porządku, ale nie jest tego samego typu. Celem jest raczej zapewnienie korzyści we właściwym przypadku niż ochrona przed złem przypadkiem.

Więc jeśli i Enumtak nie były obsługiwane „specjalnie” w Javie, można (jak zauważono w komentarzach) utworzyć następujące typy:

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

Secondwdrożyłby Comparable<First>raczej niż Comparable<Second>... ale Firstsamo byłoby w porządku.

Poniżej znajduje się zmodyfikowana wersja wyjaśnienia z książki Java Generics and Collections : We have an Enumspecified

enum Season { WINTER, SPRING, SUMMER, FALL }

który zostanie rozszerzony do klasy

final class Season extends ...

gdzie ...ma być jakoś sparametryzowaną klasą bazową dla wyliczeń. Zastanówmy się, co to ma być. Cóż, jednym z wymagań Seasonjest to, że powinien on implementować Comparable<Season>. Więc będziemy potrzebować

Season extends ... implements Comparable<Season>

Czego możesz użyć do ...tego, aby to zadziałało? Biorąc pod uwagę, że ma to być parametryzacja Enum, jedyny wybór jest Enum<Season>taki, aby mieć:

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

Tak Enumjest sparametryzowany na typach takich jak Season. Wyciągnij z Seasoni otrzymujesz, że parametr Enumjest dowolnego typu, który spełnia

 E extends Enum<E>

Maurice Naftalin (współautor, Java Generics and Collections)

Można to zilustrować prostym przykładem i techniką, której można użyć do zaimplementowania połączonych wywołań metod dla podklas. W poniższym przykładzie setNamezwraca, Nodewięc łańcuch nie zadziała dla 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
}

Moglibyśmy więc odwołać się do podklasy w ogólnej deklaracji, tak aby Cityteraz zwracał prawidłowy typ:

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

Nie tylko ty zastanawiasz się, co to znaczy; zobacz blog Chaotic Java .

„Jeśli klasa rozszerza tę klasę, powinna przekazać parametr E. Granice parametru E dotyczą klasy, która rozszerza tę klasę o ten sam parametr E”.

Ten post całkowicie wyjaśnił mi problem „rekurencyjnych typów ogólnych”. Chciałem tylko dodać kolejny przypadek, w którym ta konkretna struktura jest konieczna.

Załóżmy, że masz ogólne węzły na ogólnym wykresie:

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

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

    public Collection<T> getNeighbor();
}

Następnie możesz mieć wykresy wyspecjalizowanych typów:

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

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

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

Jeśli spojrzysz na Enumkod źródłowy, ma on następujące cechy:

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

Po pierwsze, co to E extends Enum<E>znaczy? Oznacza to, że parametr typu jest czymś, co pochodzi od Enum i nie jest sparametryzowany przez typ surowy (jest sparametryzowany przez siebie).

Jest to istotne, jeśli masz wyliczenie

public enum MyEnum {
    THING1,
    THING2;
}

który, jeśli dobrze wiem, jest tłumaczony na

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

Oznacza to, że MyEnum otrzymuje następujące metody:

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

A co ważniejsze,

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

To sprawia, że getDeclaringClass()rzut do właściwego Class<T>obiektu.

O wiele jaśniejszym przykładem jest ten, na który odpowiedziałem na to pytanie, w którym nie można uniknąć tej konstrukcji, jeśli chcesz określić ogólne ograniczenie.

Według Wikipedii ten wzór nazywa się Ciekawie powtarzający się wzór szablonu . Zasadniczo, używając wzorca CRTP, możemy łatwo odwołać się do typu podklasy bez rzutowania typów, co oznacza, że ​​używając wzorca, możemy imitować funkcję wirtualną.