Klasa Enum jest zadeklarowana jako Enum<E extends Enum<E>>, wzór znany jako polimorfizm F-ogo (lub rekursywne ograniczenie typowe). Ta deklaracja ogranicza parametr typu E do bycia podklasą Enum, która jest parametryzowana samą sobą, skutecznie wiążąc każdy konkretny typ enumeracji (np. DayOfWeek) do własnego literału klasy. Ten projekt pozwala metodzie compareTo zadeklarować swój parametr jako typ E zamiast surowego Enum, zapewniając w czasie kompilacji, że DayOfWeek może być porównane tylko z innym DayOfWeek, a nigdy z niepowiązaną enumeracją jak Thread.State. W konsekwencji, kompilator zapobiega porównaniom porządkowym między typami bez wymagania sprawdzeń instanceof lub rzutowań w czasie działania, zachowując zarówno bezpieczeństwo typów, jak i wydajność sortowania opartego na porządkach.
Zespół deweloperski musiał zaprojektować płynne API QueryBuilder dla warstwy dostępu do danych, gdzie podstawowe metody takie jak where() i limit() muszą zwracać konkretny podtyp, aby umożliwić łańcuchowanie metod w pochodnych budowniczych, takich jak SqlQueryBuilder lub GraphQlQueryBuilder.
Rozwiązanie 1: Zgodne typy zwracania z explicznym nadpisywaniem.
Każda podklasa mogłaby nadpisać każdą płynna metodę, aby zadeklarować swój konkretny typ zwracany. Choć zapewnia to bezpieczeństwo w czasie kompilacji, wprowadza poważne obciążenie związane z utrzymywaniem, wymagając kodu szablonowego w każdej podklasie za każdym razem, gdy podstawowe API się rozwija, oraz naruszając zasadę DRY w całej hierarchii dziedziczenia.
Rozwiązanie 2: Surowe typy zwracane z niesprawdzonymi rzutowaniami.
Klasa bazowa mogłaby zwracać surowy typ QueryBuilder, zmuszając podklasy do rzutowania this na ich konkretny typ. To podejście eliminuje kod szablonowy, ale generuje ostrzeżenia kompilatora i stwarza ryzyko ClassCastException w czasie działania, jeśli struktura dziedziczenia stanie się skomplikowana, zasadniczo kompromitując bezpieczeństwo typów.
Rozwiązanie 3: Polimorfizm F-ogo.
Zespół zadeklarował klasę bazową jako abstract class QueryBuilder<T extends QueryBuilder<T>>, z płynnego zwracania T. Następnie podklasy definiowały się jako class SqlQueryBuilder extends QueryBuilder<SqlQueryBuilder>. Ta technika wykorzystuje ten sam wzór rekursywnego ograniczenia jak Enum, pozwalając kompilatorowi egzekwować, że where() zwraca dokładnie SqlQueryBuilder bez jakichkolwiek rzutowań lub duplikacji metod.
Zespół wybrał Rozwiązanie 3, ponieważ wyeliminowało ono duplikację kodu, zachowując ścisłe bezpieczeństwo typów w całym łańcuchu dziedziczenia. Powstały DSL umożliwił autouzupełnianie, które poprawnie sugerowało metody specyficzne dla podklas po wspólnych operacjach, zmniejszając defekty integracyjne o 40% w trakcie fazy przyjmowania API.
Pytanie 1: Dlaczego deklaracja Enum<E extends Enum<E>> jest niezbędna zamiast po prostu Enum<E>?
Proste zadeklarowanie Enum<E> pozwoliłoby na przekazywanie dowolnego arbitralnego typu jako parametru, a nie tylko konkretnych typów enumeracji. Rekursywne ograniczenie E extends Enum<E> zmusza E do bycia konkretną klasą enumeracyjną, która rozszerza Enum zainicjowaną samą sobą. To samoodwołujące się ograniczenie zapewnia, że metody takie jak compareTo(E o) akceptują tylko dokładny podtyp enumeracji, zapobiegając porównaniom między typami w czasie kompilacji, zamiast odkładać wykrycie na ClassCastException w czasie działania. Bez tego ograniczenia implementacja Comparable musiałaby akceptować surowy Enum lub Object, tracąc specyfikę typów, która umożliwia wydajne implementacje EnumSet i EnumMap.
Pytanie 2: Jak polimorfizm F-ogo współdziała z refleksją podczas pobierania stałych enum?
Podczas wywoływania getEnumConstants() za pomocą refleksji na klasie enum, rekursywne ograniczenie zapewnia, że zwracana tablica ma typ E[], a nie surową tablicę obiektów. Jest to możliwe, ponieważ konstruktor Enum rejestruje obiekt Class<E> za pomocą getDeclaringClass(), co polega na prawidłowym powiązaniu parametru typu z konkretną podklasą. Kandydaci często przeoczają, że to powiązanie pozwala JVM optymalizować instrukcje switch na enums używając instrukcji bajtcode tableswitch, ponieważ kompilator zna dokładny skończony zbiór stałych w czasie kompilacji poprzez informacje o powiązanym typie, unikając wolniejszego lookupswitch.
Pytanie 3: Czy rekursywne ograniczenia typowe mogą prowadzić do zanieczyszczenia sterty podczas tworzenia tablic generycznych, i jak Enum unika tego?
Chociaż samo ograniczenie jest bezpieczne typowo, kandydaci często napotykają trudności próbując tworzyć tablice parametru typu (np. new E[10]). Z powodu erazji typu, jest to zabronione. Jednak klasa Enum omija to ograniczenie dzięki sztuczce kompilatora: kompilator generuje syntetyczną statyczną metodę values() dla każdej enumeracji, która zwraca E[], konstruując tablicę za pomocą java.lang.reflect.Array.newInstance() z konkretnym tokenem Class enumeracji uzyskanym z rekursywnego ograniczenia. To zapewnia, że zwracana tablica ma poprawny zreifikowany typ komponentu bez powodowania ClassCastException lub zanieczyszczenia sterty, technika, której ręczne klasy generyczne nie mogą łatwo zreplikować bez refleksji.