Jakie są wady implementacji singletonu z enum Java?

Tradycyjnie singleton jest zwykle implementowany jako

public class Foo1
{
    private static final Foo1 INSTANCE = new Foo1();

    public static Foo1 getInstance(){ return INSTANCE; }

    private Foo1(){}

    public void doo(){ ... }
}

Dzięki enum Java, możemy zaimplementować singleton jako

public enum Foo2
{
    INSTANCE;

    public void doo(){ ... }
}

Jak niesamowita jest druga wersja, czy są w niej jakieś wady?

(Myślałem o tym, a ja odpowiem na własne pytanie; mam nadzieję, że masz lepsze odpowiedzi)

Niektóre problemy z singlami enum:

Zaangażowanie w strategię wdrażania

Zazwyczaj „singleton” odnosi się do strategii implementacji, a nie specyfikacji API. Bardzo rzadko Foo1.getInstance()publicznie deklaruje, że zawsze zwróci tę samą instancję. W razie potrzeby implementacja Foo1.getInstance()może ewoluować, na przykład zwracając jedną instancję na wątek.

Z Foo2.INSTANCEPublicznie oświadczam, że ten przypadek jest instancji i nie ma szans, by to zmienić. Strategia wdrażania posiadania pojedynczej instancji jest ujawniona i zobowiązana.

Ten problem nie jest paraliżujący. Na przykład Foo2.INSTANCE.doo()może polegać na lokalnym obiekcie pomocniczym wątku, aby skutecznie mieć instancję dla wątku.

Rozszerzanie klasy Enum

Foo2rozszerza super klasę Enum<Foo2>. Zwykle chcemy unikać superklas; zwłaszcza w tym przypadku narzucona Foo2superklasa nie ma nic wspólnego z tym, co Foo2powinno być. Jest to zanieczyszczenie dla hierarchii typów naszej aplikacji. Jeśli naprawdę chcemy superklasy, zwykle jest to klasa aplikacji, ale nie możemy, Foo2superklasa jest naprawiona.

Foo2dziedziczy niektóre zabawne metody instancji name(), cardinal(), compareTo(Foo2), które są po prostu mylące dla Foo2użytkowników. Foo2nie może mieć własnej name()metody, nawet jeśli ta metoda jest pożądana w Foo2interfejsie.

Foo2 zawiera także kilka zabawnych metod statycznych

    public static Foo2[] values() { ... }
    public static Foo2 valueOf(String name) { ... }
    public static <T extends Enum<T>> T valueOf(Class<T> enumType, String name)

co wydaje się bezsensowne dla użytkowników. Singleton zazwyczaj nie powinien mieć metod statycznych pulbic (inaczej niż getInstance())

Serializacja

Singletony są bardzo częste. Te singletony zasadniczo nie powinny być serializowane. Nie mogę wymyślić żadnego realistycznego przykładu, w którym sensowne byłoby transportowanie stanowego singletonu z jednej maszyny wirtualnej na inną maszynę wirtualną; singleton oznacza „unikalny w obrębie maszyny wirtualnej”, a nie „unikalny we wszechświecie”.

Jeśli serializacja naprawdę ma sens dla stanowego singletonu, singleton powinien jawnie i precyzyjnie określić, co to znaczy deserializować singleton na innej maszynie wirtualnej, gdzie singleton tego samego typu może już istnieć.

Foo2automatycznie stosuje uproszczoną strategię serializacji / deserializacji. To tylko wypadek, który czeka. Jeśli mamy drzewo danych koncepcyjnie odnoszące się do zmiennej stanu Foo2w VM1 w t1, poprzez serializację / deserializację wartość staje się inną wartością - wartością tej samej zmiennej Foo2w VM2 w t2, tworząc trudny do wykrycia błąd. Ten błąd nie przydarzy się niemożliwym do znalezienia w Foo1ciszy.

Ograniczenia kodowania

Są rzeczy, które można zrobić w normalnych klasach, ale zabronione w enumklasach. Na przykład dostęp do pola statycznego w konstruktorze. Programista musi być bardziej ostrożny, ponieważ pracuje w specjalnej klasie.

Wniosek

Piggybacking na enum oszczędzamy 2 linie kodu; ale cena jest zbyt wysoka, musimy dźwigać wszystkie bagaże i ograniczenia wyliczeń, mimowolnie dziedziczymy „cechy” wyliczenia, które mają niezamierzone konsekwencje. Jedyną rzekomą zaletą - automatyczna serializacja - okazuje się być wadą.

Instancja wyliczenia zależy od modułu ładującego klasy. tzn. jeśli masz moduł ładujący drugiej klasy, który nie ma modułu ładującego pierwszej klasy jako element nadrzędny ładujący tę samą klasę enum, możesz uzyskać wiele instancji w pamięci.

Próbka kodu

Utwórz następujący wyliczenie i umieść sam plik .class w słoju. (oczywiście słoik będzie miał poprawną strukturę pakietu / folderu)

package mad;
public enum Side {
  RIGHT, LEFT;
}

Teraz uruchom ten test, upewniając się, że nie ma kopii powyższego wyliczenia na ścieżce klasy:

@Test
public void testEnums() throws Exception
{
    final ClassLoader root = MadTest.class.getClassLoader();

    final File jar = new File("path to jar"); // Edit path
    assertTrue(jar.exists());
    assertTrue(jar.isFile());

    final URL[] urls = new URL[] { jar.toURI().toURL() };
    final ClassLoader cl1 = new URLClassLoader(urls, root);
    final ClassLoader cl2 = new URLClassLoader(urls, root);

    final Class<?> sideClass1 = cl1.loadClass("mad.Side");
    final Class<?> sideClass2 = cl2.loadClass("mad.Side");

    assertNotSame(sideClass1, sideClass2);

    assertTrue(sideClass1.isEnum());
    assertTrue(sideClass2.isEnum());
    final Field f1 = sideClass1.getField("RIGHT");
    final Field f2 = sideClass2.getField("RIGHT");
    assertTrue(f1.isEnumConstant());
    assertTrue(f2.isEnumConstant());

    final Object right1 = f1.get(null);
    final Object right2 = f2.get(null);
    assertNotSame(right1, right2);
}

A teraz mamy dwa obiekty reprezentujące „tę samą” wartość wyliczenia.

Zgadzam się, że jest to rzadki i przemyślany przypadek narożny, i prawie zawsze można zastosować wyliczenie dla singletona Java. Robię to sam. Ale pytanie o potencjalne wady i ta uwaga są warte poznania.

wzorzec wyliczenia nie może być użyty dla żadnej klasy, która zgłasza wyjątek w konstruktorze. Jeśli jest to wymagane, użyj fabryki:

class Elvis {
    private static Elvis self = null;
    private int age;

    private Elvis() throws Exception {
        ...
    }

    public synchronized Elvis getInstance() throws Exception {
        return self != null ? self : (self = new Elvis());
    }

    public int getAge() {
        return age;
    }        
}