Co można powiedzieć o typach wyliczeniowych (enums)? Choćby to, że przydają się tam, gdzie mamy do czynienia ze stanami lub atrybutami, które należą do jakiegoś skończonego zbiory. Z technicznego punktu widzenia to kilka(naście/dziesiąt/set) liczb nazwanych stałymi identyfikatorami. I zazwyczaj języki programowania nie oferują wiele ponad to.
Lecz Java musiała się tu wyróżnić :) Z wierzchu jej enum
y wyglądają niby zwyczajnie:
ale w środku kryją bardzo szerokie i pewnie trochę udziwnione możliwości…
Zacznijmy od tego, że takie stałe wyliczeniowe są bezpieczne pod względem typowania – nie można więc jawnie rzutować ich na zwykłe liczby typu int
. Słowo kluczowe enum
tworzy też – podobnie jak w C# – przestrzeń nazw, więc do stałych odwołujemy się nazwami kwalifikowanymi (Answer.YES
) i nie trzeba stosować żadnych przedrostków.
Ale to są wręcz oczywistości. Kolejnym punktem programu jest możliwość dostępu do zbioru zadeklarowanych stałych oraz ich wypisywania w postaci tekstowych nazw:
Takie nazwy mogą być jednak brzydkie. Żaden problem, bowiem w Javie z każdą stałą może być związany dowolny zestaw danych:
które – jak widać – deklarujemy podobnie jak składniki klas. A poszczególne “stałe” typu wyliczeniowego nie są już na pewno tylko liczbami: to pelnoprawne obiekty:
Widzimy, że metody są również dozwolone. Żeby było śmieszniej, mogą być one nawet “wirtualne”. Możemy bowiem zapewnić, aby inne ich wersje były wywoływane dla różnych stałych. Robi wrażenie, prawda?…
Cóż, pewnie niekoniecznie – zwłaszcza, że nietrudno osiągnąć podobną funkcjonalność przez instrukcję wyboru. Zgoda, będzie ona bardziej podatna i trudniejsza w konserwacji. Lecz jeśli alternatywą jest przeładowanie języka dziwnymi i nie do końca oczywistymi mechanizmami, to stary dobry switch
niekoniecznie musi być rozwiązaniem złym.
Co oczywiście nie zabrania nam być pod wrażeniem pomysłowości twórców języka Java :-)
Nie string, a String ;)
True. Ale nie zmienia to faktu, że GeSHi coś słabo sobie radzi z kolorowaniem tych wynalazków z Javy nr 5 :)
“(…) takie stałe wyliczeniowe są bezpieczne pod względem typowania – nie można więc jawnie rzutować ich na zwykłe liczby typu int. (…) Ale to są wręcz oczywistości.”
Nie bardzo rozumiem, dlaczego niemożność konwersji enum->int jest oczywistością ;).
Bo tylko w C++ enumy to niemal to samo co liczby, podczas gdy faktycznie są to tylko skończone zbiory, które mogą reprezentować cokolwiek. To, że akurat wszyscy przyzwyczaili się, że “w środku” są to liczby, nie zawsze musi być prawdą (Java to pokazuje). I nawet jeśli jest, nie powinno się tak łatwo konwertować je na liczby.
Nie wiem czemu, ale wydaje mi się to trochę przekombinowane. Ale nie znam zbyt dobrze Javy, więc pewnie tylko mi się wydaje ;)
Czemu przekombinowane? To ma być enum i tę funkcję pełni dobrze. A dodatkowych bajerów używać nie musisz :)
@brodny dokładnie
Funkcja enumów spełniona, a te bajery z enumów parę razy mi się przydały, więc nie marudzić.
Takie fajne enumy wyszły im właściwie przez przypadek. Wprowadzono je dopiero w Javie 1.5, a Sun ma zasadę, że kod jest kompatybilny z poprzednimi wersjami, więc musiano użyć jakiegoś już istniejącego elementu języka. Enum jest w rzeczywistości klasą (kompiluje sie do *.class).
Co powoduje, że trzeba każdego – nawet najmniejszego enuma – deklarować w osobnym pliku. No ale to jest generalna przypadłość Javy :)
Ale to też powoduje, że mam przejrzysty podział na klasy i że się nie gubię w kodzie źródłowym :)
Ja w każdym języku stosuje się do trzymania jednej klasy w jednym pliku.
Nie nazwałbym wymuszania deklaracji enuma w oddzielnym pliku przejrzystym podziałem :P
Już rzut oka na definicję klasy bazowej dla typów wyliczeniowych w Javie wskazuje dobitnie, że należy je traktować poważnie
public abstract class Enum<E extends Enum>
implements Comparable, Serializable {
}
@Kurak
Nikt nie wymusza deklaracji enuma w oddzielnym pliku.