Singleton - sens użycia

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?

1. Nie bardzo rozumiem co ma wspólnego singleton z klasą abstrakcyjną
2. 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.

1. 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):

1. 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.