Zastanawiam się nad sensem używania tego wzorca.
Czy ma on rację bytu tylko w projektach grupowych?
Dlaczego przy małym projekcie nie zastąpić tego klasą abstrakcyjną lub publicznym obiektem inicjalizowanym na samym starcie?
- Nie bardzo rozumiem co ma wspólnego singleton z klasą abstrakcyjną
-
publicznym obiektem inicjalizowanym na samym starcie
to jest przecież właśnie singleton...
Generalnie singletonami robi się bezstanowe klasy serwisowe, takie które realizują jakąś logikę. Zamiast upychać całą logikę aplikacji w jakichś Bogu ducha winnych obiektach, wyciągasz ją poza taki obiekt do serwisu a potem w tym obiekcie tylko używasz. Ma to między innymi takie plusy że możesz tego samego serwisu używać w wielu miejscach, poza tym jest lepsze z punktu widzenia zasady jednej odpowiedzialności. No i łatwiej sie to potem testuje.
- Pfu! miałem na myśli klasę statyczną. Statyczne metody mogą równie dobrze spełniać rolę globalnych zadań jak np logi programu. Mylę się?
Shalom napisał(a):
poza tym jest lepsze z punktu widzenia zasady jednej odpowiedzialności. No i łatwiej sie to potem testuje.
Wszelkie opisy jakie znajduję mówią zupełnie odwrotnie. Nawet opis na wikipedii.
Bo te opisy zakładają że robisz ten singleton "na pałe" poprzez statyczną metodę dostępową. A ja mówie o singletonie z kontenera IoC, który nie ma wad zywkłego singletonu, bo jest wstrzykiwaną zależnością. W efekcie testowanie jest banalne bo podmieniasz wstrzykiwany obiekt :)
Ze staticami jest taki problem że to się dopiero ciężko testuje*
;]
*
w niektóych językach. Taki python ze swoim monkey-patchingiem to nie ma z tym żadnych problemów ;)
Krzywy Krawiec napisał(a):
- Pfu! miałem na myśli klasę statyczną. Statyczne metody mogą równie dobrze spełniać rolę globalnych zadań jak np logi programu. Mylę się? .
Metody statyczne ciężko się mockuje, czyli klasy klienckie są trudne do przetestowania. Z drugiej strony w scali singletony są wbudowane w składnie i są tworzone właśnie przez metody statyczne, więc coś musi w tym być.
Raz odziedziczyłem projekt, w którym ktoś maił zamiłowanie do singletonów (+20).
To było straszne, bo na dodatek singletony zależały od siebie.
Jak miałem dodać jakąś funkcjonalność to co rusz natrafiałem na problem kolejności inicjalizacji (wielowątkowy oczywiście) i po prostu nie dało się tego naprawić bez wprowadzenia nowych błędów.
Singletonów powinno być mało: dla aplikacji, dla logowania i tyle. A jeśli singletony zależą od siebie, to znaczy, że masz coś totalnie źle.
Ludzie lubią stosować singletony, bo wydaje im się że ich implementacja jest prosta (napisanie szybkiego singletona w C++ to jest niezła jazda). Jest to pierwszy wzorzec, którego się uczą i wydaje im się, że go od razu rozumieją jak i kiedy go używać. Prawda jest taka, że najczęściej jest to wytrych na zmienne globalne (udajemy, że ich nie mamy).
Zdecydowanie jest to wzorzec nadużywany i przeceniany.