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
  • Odpowiedz
  • 0
@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).
  • Odpowiedz
@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.
  • Odpowiedz
@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.
  • Odpowiedz
  • 1
@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".
  • Odpowiedz
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ł? ( ͡° ͜ʖ ͡°)
  • Odpowiedz
@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
  • Odpowiedz
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.
  • Odpowiedz