Singleton (wzorzec projektowy)
W dzisiejszym artykule zagłębimy się w fascynujący świat Singleton (wzorzec projektowy). Od samego początku do chwili obecnej Singleton (wzorzec projektowy) był tematem zainteresowania, który przykuł uwagę wielu ludzi na całym świecie. W tym artykule zbadamy różne aspekty Singleton (wzorzec projektowy), w tym jego historię, ewolucję, wpływ na społeczeństwo i jego dzisiejsze znaczenie. Dzięki szczegółowej analizie odkryjemy powody, dla których Singleton (wzorzec projektowy) wzbudził tak duże zainteresowanie i jak wpłynął na różne obszary codziennego życia. Przygotuj się na zanurzenie się w ekscytującym świecie Singleton (wzorzec projektowy) i odkryj wszystko, co ten motyw ma do zaoferowania!
Singleton – kreacyjny wzorzec projektowy, 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[1]. Niektórzy programiści uznają go za antywzorzec, ponieważ łamie zasady projektowania obiektowego, często bywa nadużywany[2] lub sprowadza się do stworzenia obiektowego zamiennika dla zmiennej globalnej[3][4].
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].
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.
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.
Konsekwencje stosowania
Zalety:
- singleton nie musi ograniczać się do obsługi pojedynczej instancji klasy – przy niewielkiej zmianie podejścia można za jego pomocą zarządzać także większą liczbą obiektów,
- klasa zaimplementowana z użyciem wzorca singleton może samodzielnie kontrolować liczbę swoich instancji istniejących 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:
- brak elastyczności, bo już na poziomie kodu jest na sztywno określona liczba instancji, jakie mogą istnieć w systemie
- poważnie utrudnia testowanie aplikacji przez wprowadzenie do niej globalnego stanu
- łamie zasadę jednej odpowiedzialności
- łamie zasadę otwarte-zamknięte
- nie można go rozszerzyć
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.
Przykłady
Podobne wzorce
Przypisy
- ↑ Mark Townsend: Exploring the Singleton Design Pattern. . (ang.).
- ↑ a b 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
Bibliografia
- Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides: Inżynieria oprogramowania: Wzorce projektowe (Wyd. II). Warszawa: WNT, 2008, s. 143-151. ISBN 978-83-204-3472-9.