Java wymyśla zastosowania i możliwości zmienności?

Question

Nie wiem, czy tylko ja to wiem, ale wartości wyliczenia nie są domyślnie ostateczne i można je modyfikować.

enum EnumTest { 
    TOTO("TOTO 1"), 
    TATA("TATA 2"), 
    ; 

    private String str; 

    private EnumTest(String str) { 
     this.str = str; 
    } 

    @Override 
    public String toString() { 
     return str; 
    } 
    } 

    public static void main(String[] args) { 
    System.out.println(EnumTest.TATA); 
    EnumTest.TATA.str = "newVal"; 
    System.out.println(EnumTest.TATA); 
    } 

TATA 2 
newVal 

Wartości te są oftenly zainicjowana podczas tworzenia instancji (TOTO("TOTO 1")), ale oprócz mnie, nigdy nie widziałem nikogo, używając końcowego słowa kluczowego enum dla zmiennych, które powinny być niezmienne. Nie o to chodzi, tylko zastanawiam się, czy jestem tego jedyny świadomy.

Co chciałbym wiedzieć, czy był jakiś przypadek, aby utworzyć zmienne wyliczenia?

Chciałbym również poznać granice tego, co możemy zrobić z wyliczeniem (dobra praktyka lub nie). Nie testowałem tego, ale może enum może zostać wstrzyknięty fasolą Spring? Przynajmniej wydaje się, że możemy opisać każdą instancję (@Deprecated działa dobrze na przykład), a także metody.

Answer 1

Jednym z możliwych przykładów użycia byłoby leniwy inicjowanie (obliczyć niektóre wartości pól, gdy są po raz pierwszy używane, jeśli często nie są w ogóle używane) lub "normalny", zmienny obiekt singletowy (jak rejestr lub inny).

W większości przypadków obiekty enum powinny być niezmienne, a ich pola muszą być ostateczne.

Answer 2

Co chciałbym wiedzieć, czy był jakiś przypadek, aby utworzyć zmienne wyliczenia?

Stałe enum nie są same w sobie zmienne, ich pola są zmienne.

Answer 3

Podczas wskazania interesującego faktu tutaj, o ile mi wiadomo, nie ma tu zastosowania dla zmiennych pól wyłudzeniowych. Istnieje wiele powodów, dla których wykorzystanie "funkcji" tego języka ("błędu"?) Byłoby złym pomysłem, a jednym z nich jest możliwość pomylenia innych programistów.

Answer 4

W odpowiedzi na odpowiedź i komentarz Alexa, przyjmuję jego sugestię o zamieszczeniu możliwego przypadku użycia. Weźmy stary standardowy przykładowy planeta, z której można obliczyć grawitację. Wyobraź sobie, że chcesz utrzymać liczbę ludzkich kolonii na każdej planecie. Tak, możesz użyć EnumMap, ale mógłbym zobaczyć przypadek, w którym może być potrzebnych coraz więcej zmiennych pól, a posiadanie osobnej mapy dla każdej wartości lub osobnej klasy, która utrzymywałaby zmienne wartości związane z wyliczeniem, byłoby sprzeczne z intuicją.

Jak już stwierdziłem w moich komentarzach, ogólnie sądzę, że wyliczenia zwykle są i powinny być niezmienne, ale uważam, że stwierdzenie, że nie ma przypadków użycia, jest zbyt silne.

Answer 5

Nie widzę powodu, aby zabronić używania zmiennych pól w enum s. Jeden używa enum do stwierdzenia, że ​​wartość typu należy do jednego ze skończonych (i znanych) zestawów możliwości. Nie oznacza to, że wartości te nie mogą mieć właściwości, które ewoluują w czasie.

Niektórzy pytali o przypadki użycia takiego scenariusza. Jednym z przykładów może być użycie typu enum, takiego jak ErrorCategory, który klasyfikowałby błąd do jednej z wielu predefiniowanych kategorii (np .: DocumentationError, SemanticError, LayoutError ...).

Załóżmy, że te ErrorCategories mają właściwości, takie jak requiresInstantIntervention lub shouldFailBuild. Mogę sobie wyobrazić, że wartość tych właściwości może zmieniać się w czasie lub że mogą być konfigurowane przez użytkownika.

Zdaję sobie sprawę, że istnieje (wiele) innych sposobów na jego wdrożenie (takich jak wspomniana wyżej EnumMaps) i zawsze można się spierać o styl, ale dla mnie takie użycie enum s nie jest samo w sobie złe. Ponieważ enum s są typami referencyjnymi w java, zachowanie == pozostaje takie samo, jak gdyby nie było żadnych właściwości zmiennych.

Answer 6

Instancja wyliczeniowa jest publicznym statycznym końcowym polem klasy wyliczeniowej. Więc jeśli jest zmienna, możesz zmienić jej stan w innym wątku. Może nie być to, co chcesz i może powodować problemy, jeśli nie zdajesz sobie z tego sprawy.