Wzorzec Singleton

Cześć Wam!

Dzisiaj będzie wyjątkowo krótko ponieważ chciałbym poruszyć dość popularny temat. Pod kątem programistycznym chciałbym pociągnąć temat wzorców projektowych trochę dalej i tym razem opisać coś, co z pewnością osoby będące na studiach / z wyższym wykształceniem informatycznym kojarzą. Mowa o Singletonie – czyli wzorcu o którym czasami mówi się anty-wzorzec. Omówię jego podstawową implementację, wady, zalety i dlaczego moim zdaniem nie jest najważniejszym wzorcem. Do dzieła!

Singleton ogólnie

Singleton jest jednym ze wzorców zdefiniowanych przez GoF (Gang of Four). Jest konstrukcyjnym wzorcem projektowym. Jak już wspomniałem w wstępie, większość osób z wykształceniem IT były uczone tego wzorca jako podstawy. Sam wzorzec mówi nam o tym, że w aplikacji będzie używany tylko jeden obiekt danego typu. Dla lepszego zwizualizowania sobie problemu: wyobraźmy sobie, że w naszym systemie potrzebujemy zainicjować obiekt, który będzie zainicjowany tylko ten jeden raz. Po co komu taki obiekt? Załóżmy, że za pomocą tego obiektu będziemy łączyć się z bazą danych (każde kolejne zainicjowanie takiego obiektu mogłoby skutkować zerwaniem połączenia) lub można również założyć, że taki obiekt będzie zawierał informacje, statystyki czy ważne ustawienia. Każda ponowna inicjalizacja mogłaby skończyć się np nieumyślną zmianą zapisanych ustawień.

Przykładowa implementacja

Najprostsza implementacja składa się z:

1. prywatnego konstruktora domyślnego i prywatnego konstruktora kopiującego (jeżeli język umożliwia jego tworzenie np. C++), które wykluczają tworzenie instancji poza obiektem

2. prywatnego statycznego pola reprezentującego jedyną instancję singletonu

3. metody dostępowej zwracającej instancję singletona

public class SimpleSingleton {
    private static SimpleSingleton instance;
    private SimpleSingleton() {
    }
 
    public static SimpleSingleton getInstance() {
        if (instance == null)
            instance = new SimpleSingleton();
        return instance;
    }
}

Problem

Wydaje mi się, że paradoksalnie największym problemem singletona jest to, że większość współczesnych aplikacji jest wielowątkowa. W aplikacjach webowych często dzieje się to zupełnie bez naszej wiedzy. Może dojść do takiej sytuacji, w której dwa nasze wątki w tym samym czasie będą chciały zainicjować obiekt, w skutek czego powstaną dwa singletony w systemie. Stąd też dość częste opinie o Singletonie, że jest to raczej anty-wzorzec.

Rozwiązanie problemu

Jak to w programowaniu, są różne sposoby, które nadal możemy nazywać singleton (idea zostaje zachowana — mamy tylko jedną instancję, ale nie ‘wymuszamy’ tego, a raczej konfigurujemy w ten sposób). Przykładem użycia tego wzorca jest Spring Framework. W przypadku Springa, każdy element (domyślnie), który oznaczymy jako nasz serwis (@Service) jest Singletonem (ale nie musi być).

Reasumując, jedną z istotnych rzeczy jest to by zapamiętać, że Singleton jest przydatnym wzorcem, ale jego implementacja kojarzona z uczelni może mieć przykre konsekwencje. Użycie Singletona w Springu jako serwis poruszę w osobnym wpisie, bo zdaję sobie sprawę, że jest do dość trudny i obszerny temat. Zapraszam za tydzień na wpis o charakterze biegowym!