Wpis z mikrobloga

@MATAHAMARA: nie wiem do końca ocb. z tym auto ale zasadniczo masz prywatny konstrutor (1) w kodzie żeby nie dało się utworzyć jej instancji z palca przez new AutoInstanceSingleton().
Dalej masz statyczną metodę która zawsze zwraca tą samą instancję klasy (2).
Nie znam dobrze c# ale użycie to pewnie:
AutoInstance
Singleton myInstance = AutoInstanceSingleton.Auto();
AutoInstance
Singleton myInstance2 = AutoInstance_Singleton.Auto();
if(myInstance == myInstance2) {
// prawda to
}
Kod ogólnie
Domyślam się, bo to gówno program, który ma ukazać działanie singletona


@MATAHAMARA: Singleton to zła praktyka, a nawet gdyby, to jest to chyba najgorszy sposób robienia singletona, a nawet gdyby, to cały pozostały kod przyćmiewa resztę.

public sealed class Singleton
{
private static readonly Singleton instance = new Singleton();

static Singleton()
{
}
private Singleton()
{
}
public static Singleton Instance
{
get
{
return instance;
}
}
}

Singleton s
@MikelThief singleton jest antywzorcem, bo z definicji ma co najmniej dwie odpowiedzialności: zarządzanie swoim lifecycle i to co w rzeczywistości ma robić. Można mieć singletony w aplikacji, ale ich lifecycle powinien być zarządzany przez coś innego (zwykle DI).
@Yahoo_: singleton jest antywzorcem tylko dla tych zabawnych dogmatycznych programistów dla których wszystko jest czarne lub białe. Programiści którzy do rozwiązań programistycznych podchodzą pragmatycznie wiedzą że singletona da się wykorzystać w modelowaniu pewnej rzeczy bądź sytuacji, a DI to nie jest panaceum.
@MikelThief: Mieć globalną metodę, która daje dostęp do instancji klasy z każdego miejsca vs utworzyć jej instancję w odpowiednim miejscu i przekazać do części aplikacji, które jej faktycznie wymagają.
Fakt łatwiej i szybciej zrobić singleton a w prostych apkach to może być nawet lepsze rozwiązanie jeżeli zestawimy czas implementacji i eksploatacji. Ale nie oszukujmy się to jest droga na skryty anty pattern nie anty pattern nie istotne.
@MikelThief świadomość, że coś jest antywzorcem nie sprawia, że nie możesz tego użyć, bo magicznie uderzy Cię piorun :p. I uwierz mi stanowczo częściej niż bym chciał muszę podejmować decyzje pomiędzy "co powinno być zrobione" a "co można zrobić w akceptowalnym czasie".
utworzyć jej instancję w odpowiednim miejscu i przekazać do części aplikacji, które jej faktycznie wymagają.

@bmLq: I bedziesz logger do każdego obiektu który coś loguje przekazywał? ( ͡° ͜ʖ ͡°)
@Strus: zdecydowanie, nie każda klasa coś loguje. Jeżeli trzymasz się solida i rozbijasz kod tak żeby się go łatwo testowało jednostkowo powiedziałbym wręcz że duża większość klas nic nie loguje. No i jak masz kilka logerow do różnych plików to łatwiej te logi potem przeglądać ( a singleton wyklucza możliwość stworzenia kilku logerow ;) . Czy w testach potrzebujesz logi? Wiem że to znikomy wpływ na czas wykonania ale jednak przy
Czy w testach potrzebujesz logi? Wiem że to znikomy wpływ na czas wykonania ale jednak przy logerze jako zależność możesz go zastąpić jakimś NullLoggerem w testach.

@bmLq: Jak masz logger jako Singleton to też możesz.

zdecydowanie, nie każda klasa coś loguje.

Zdecydowanie większość powinna. Przynajmniej w mojej branży, gdzie w przypadku crasha lub błędu gdzieś na testach całego produktu praktycznie większość informacji jest tylko w logach i coredumpie.