Czy obiekty enum powinny być bezpaństwowcami?

Question

Zgodnie z projektem stała wyliczeniowa w java jest singletonem, a ze względu na równoczesne użycie normalnie tworzę instancje instancje bezstanowe i stosuję parametry metody do wstrzykiwania danych w razie potrzeby.

Przykład:

Obecnie tworzę usługi REST, która prowadzi działalność (zaimplementowany jako enum przy użyciu wariant wzorca strategii).

public enum Operation { 

    DO_THIS() { 
    public Result doSomething(Object theData) { 
    } 
    } , 
    // Other Operations go here 
    ; 

    public abstract Result doSomething(Object theData); 

} 

Teraz chcę zebrać dane o tym, jak często operacja została wywołana i jak często się to powiodło i tym podobne.

Mogłem zapisać stan zewnętrznie podczas korzystania z instancji wyliczenia, ale wydaje się raczej, że stan powinien być zapisany w operacji, ponieważ operacja powinna zawierać własny stan.

Teraz moje ogólne pytanie brzmi:

Czy Stateful instancji enum (oprócz z kwestiami współbieżności) złej konstrukcji?

Answer 1

Myślę, że narusza to zasadę najmniejszego zdziwienia.

Ludzie oczekują wspólnego użycia wyrażeń tak jak były pierwotnie projektowane - jako stałych lub tokenów, a nie jako klas ogólnego przeznaczenia ze stanem.

Answer 2

Wydaje się, że jest to niewłaściwy użytek do wyliczenia - dlaczego nie po prostu iść z podstawową klasą abstrakcyjną z nową podklasą dla każdej operacji?

Answer 3

Tak. I przez "tak" mam na myśli "Zawsze".

Jeśli chcesz zestawiać statystyki dotyczące liczby wywoływanych operacji, zaimplementuj obserwowalność.

Answer 4

Każda forma zmiennego statycznego jest grzechem. (Cóż, możesz uciec z nieszczelnymi pamięciami podręcznymi, leniwą inicjalizacją i formami logowania.)

Answer 5

Całkowicie zgadzam się z mparazem, że narusza zasadę najmniejszego zdziwienia. Ludzie oczekują, że wyrazy są stałe.

Można niemal na pewno działa okrągły rzeczy logowania, za coś takiego:

DO_THIS() { 
    public Result doSomething(Object theData) { 
    MyUtilClass.doSomething(Object theData); 
    } 
} 

rejestrowanie i umieścić w drugiej klasie.

JEDNAK, jeśli nie możesz tego obejść, zasada najmniejszego zdziwienia jest wytyczną; możesz go naruszyć ZARABIAJ, że dajesz użytkownikom klasy wystarczająco ostrzeżenia o tym, co się dzieje. Upewnij się, że deklaracja enum zawiera dużą informację, że jest zmienna i dokładnie opisuje, na czym polega zmienność. Enum powinno nadal działać; wykonuje porównanie porównawcze z pojedynczą instancją, aby przetestować wartości wyliczeniowe.

Answer 6

Kociak umiera za każdym razem, gdy tworzy się wymuszone wyliczenie. Uratuj kotki!

Answer 7

Wyliczenie stanowe to oksymoron, a nawet anty-wzór!

http://en.wikipedia.org/wiki/Enumeration

Wyliczenie to zbiór elementów, które jest kompletnym, nakazał listę wszystkich elementów w tej kolekcji. Termin ten jest powszechnie używany w matematyce i informatyce teoretycznej, aby odnosić się do listy wszystkich elementów zbioru. W statystykach używany jest termin kategoryczna zmienna, a nie wyliczanie. Dokładne wymagania dotyczące wyliczenia (na przykład, czy zbiór musi być skończony, czy też lista może zawierać powtórzenia) zależą od dziedziny matematyki i kontekstu, w którym się pracuje.

Wyliczenia mają skończoną liczbę wartości, które powinny być stałe, którymi są.

Jednak fakt, że są one "pierwszorzędnymi" obiektami Java, jest całkowicie sprzeczny z intencją lub duchem wyliczenia.

Jeśli wymagany jest jakikolwiek stan, wyliczenie (jak wspomniano wcześniej) powinno zawierać stan w aspekcie lub wyłudzającym wyliczeniu, powinno to, co najmniej w praktyce, zawierać odniesienie do stanu posiadania klasy delegatów. Pomocne będzie zrozumienie "rozdzielenia spraw".

Answer 8

Istnieje przypadek, który prawdopodobnie to uzasadnił. Wyliczenie może zaimplementować interfejs, zwykle z myślą o konkretnym przypadku użycia, który pozwala tworzyć dynamicznie/w sposób "inny typ klasy enum" w sposób rutynowy/jawnie "niektóre inne typy klasy wyliczeniowej", aby w końcu ją nazwać.

Oznacza to, że instancje typu "singleton" mogą być zmuszane do implementacji sygnatur metod, które można zmodyfikować (jako setery), które oczywiście można ukryć przy użyciu pustego kodu lub wyjątku NotSupportedException.

Na szczęście metody końcowe w interfejsie nie pozwalają na żadną możliwość zmiany stanu. Byłby to jedyny "zrozumiały" przypadek, jaki mogłem wymyślić.