Singleton (wzorzec projektowy)
Z Wikipedii
Singleton jest to jeden z kreacyjnych wzorców projektowych (obiektowy), którego celem jest ograniczenie możliwości tworzenia obiektów danej klasy do jednej instancji oraz zapewnienie globalnego dostępu do stworzonego obiektu. Niekiedy wzorzec uogólnia się do przypadku wprowadzenia pewnej maksymalnej liczby obiektów, jakie mogą istnieć w systemie. Niektórzy programiści uznają go za antywzorzec, ponieważ łamie zasady projektowania obiektowego [1], często bywa nadużywany[1][2] lub sprowadza się do stworzenia obiektowego zamiennika dla zmiennej globalnej [3][4].
Spis treści |
[edytuj] Przykład zastosowania
Rozważmy aplikację prowadzącą dla celów diagnostycznych dziennik zdarzeń. Poszczególne komponenty dodają wpis do dziennika, przekazując mu jego treść, natomiast dziennik określa, gdzie faktycznie zostanie on zapisany.
- Każdy komponent może uzyskać w dowolnym momencie dostęp do dziennika, zatem musi on być dostępny globalnie.
- To dziennik decyduje o tym, gdzie wpis zostanie faktycznie zapisany. Komponent musi jedynie przekazać jego treść. Oznacza to istnienie pojedynczej instancji dziennika.
- Z dziennika mogą również korzystać komponenty wielokrotnego użytku, zatem nie powinny one być zależne od mechanizmów udostępniania zasobów specyficznych dla danej aplikacji.
Możemy to zapewnić, implementując w dzienniku wzorzec singleton tak, aby mógł on we własnym zakresie zarządzać dostępem do siebie samego[2].
[edytuj] Struktura wzorca
Singleton implementuje się przez stworzenie klasy, która posiada statyczną metodę, która najpierw sprawdza, czy istnieje już instancja tej klasy, w razie potrzeby tworząc ją. Następnie instancja zwracana jest przez referencję. Instancję przechowuje się w prywatnym lub chronionym, statycznym polu, do którego dostęp ma tylko opisana wyżej metoda, która jest jedyną drogą pozyskania instancji obiektu singletonu - aby uniemożliwić tworzenie dodatkowych instancji, konstruktor klasy deklaruje się jako prywatny lub chroniony.
Należy zauważyć, że cały proces jest niewidoczny dla użytkownika. Nie musi on wiedzieć, czy instancja już istnieje czy dopiero jest tworzona. Jeśli żaden komponent nie będzie wykorzystywać klasy, system nie przydzieli jej zasobów.
[edytuj] Konsekwencje stosowania
- Klasa wykorzystująca singleton we własnym zakresie kontroluje dopuszczalną ilość instancji, jakie mogą istnieć w systemie.
- Proces pobierania instancji klasy jest niewidoczny dla użytkownika. Nie musi on wiedzieć, czy w chwili wywołania metody instancja istnieje czy dopiero jest tworzona.
- Tworzenie nowej instancji ma charakter leniwy, tj. zachodzi dopiero przy pierwszej próbie użycia. Jeśli żaden komponent nie zdecyduje się korzystać z klasy, jej instancji nie będą niepotrzebnie przydzielone zasoby.
Wady:
- poważnie utrudnia testowanie aplikacji przez wprowadzenie do niej globalnego stanu[1][5]
- łamie zasadę jednej odpowiedzialności[1]
- łamie zasadę otwarte-zamknięte[1]
- nie można go rozszerzyć[1]
Singleton musi być ostrożnie stosowany w systemach wielowątkowych. Zażądanie instancji klasy przez dwa wątki równocześnie może doprowadzić do utworzenia dwóch niezależnych instancji, dlatego metoda dostępowa powinna być wtedy zaimplementowana z wykorzystaniem wzajemnego wykluczania.
[edytuj] Przykłady
[edytuj] Podobne wzorce
[edytuj] Bibliografia
- Inżynieria oprogramowania: Wzorce projektowe - wydanie II, WNT 2008, ISBN: 78-83-204-3472-9, str. 143-151
Przypisy
- ↑ 1,0 1,1 1,2 1,3 1,4 1,5 Jarosław Kuczyński, Singleton inaczej, grudzień 2008
- ↑ 2,0 2,1 J.B. Rainsberger, IBM, Use your singletons wisely, lipiec 2001
- ↑ Scott Densmore, Why singletons are evil, maj 2004
- ↑ Steve Yegge, Singletons considered stupid, wrzesień 2004
- ↑ Chris Reath, Singleton I love you, but you're bringing me down, październik 2008
|
||||||||||||||
