[tylko_na_dole]

Dlaczego wzorzec projektowy Singleton łamie SOLID?

#programowanie

[Saly]

@tylko_na_dole: ciężko jednoznacznie powiedzieć. Jakbym miał strzelać to literka S, bo klasa ma dużo odpowiedzialności: logika trzymania jednej instancji + reszta

[tylko_na_dole]

@Saly: chyba masz rację, dziękuję :)

[Saly]

@tylko_na_dole: tak czy owak singleton jest praktycznie nigdy nie potrzebny. Co jakiś czas próbuję znaleść jakieś zastosowanie i nie udało mi się wpaść na nic co nie ma lepszej alternatywy

[ly000]

@tylko_na_dole:
(S) rozwiązuje dwa problemy jednocześnie.
(O) nie da się rozszerzyć jego funkcjonalności przez dziedziczenie bez modyfikacji istniejącego kodu (klasy odwołują się bezpośrednio do singletonu).

[Saly]

@ly000: według mnie O jest bardziej o tym jak sama klasa jest zbudowana niż o tym jak się jej używa. Czyli czy zależności których używa klasa są interfejsami czy też nie.

No bo jaka jest różnica, jeśli w miejscu, gdzie definiuję zależności zrobię final Interface foo = Singleton.getInstance() vs final Interface foo = new NotASingleton(). W obu przypadkach literka O jest implementowana w taki sam sposób: muszę podmienić tą linię

[Krolik]

@Saly: co jeśli logikę trzymania jednej instancji zapewnia język? Wtedy klasa ma jedną odpowiedzialność. Łamie S?

[object]

@tylko_na_dole: ja bym powiedział, że tylko O bo nie da się dziedziczyć po klasie statycznej.
Drugą kwestią jest to że gdyby nawet się dało to wtedy nie jest to singleton

[tos-1_buratino]

@tylko_na_dole:

Single responsibility principle

Nie łamie bo singleton może być napisany tak aby miał tylko jedną odpowiedzialność.

Open/closed principle

Nikt nie broni napisać singletona tak aby był zamknięty na modyfikacje i otwarty na rozszerzenia.

Liskov substitution principle

W tym gównie nigdy nie wiem o co chodzi ale raczej jak będziesz miał hierarchię dziedziczących po sobie singletonów to mogą spełniać tę zasadę. Czyli nie modyfikować klas bazowych i być kompatybilne z klasami

[Krolik]

@object: od kiedy dziedziczenie jest konieczne dla Open/Closed? W ogóle rozszerzanie klasy przez dziedziczenie to rak jest. Rozszerzanie można realizować np. przez strategie, dostarczaną jako osobny obiekt, ustawianą po stworzeniu singletona.

[Krolik]

tak czy owak singleton jest praktycznie nigdy nie potrzebny.

@Saly: W sumie zgadzam się, ale jednak są rzeczy które występują w ilości zawsze dokładnie jeden: np. każda apka ma jeden strumień wejścia, jeden runtime (w Javie singleton Runtime), jeden kontekst systemowy trzymający np. ilość dostępnych zasobów itp. Często też dla uproszczenia rzeczy takie jak logowanie czy kontrola dostępu są implementowane jako singleton, choć nie muszą być. Ale najczęściej potrzebne są w

[Saly]

@Krolik: w takich przypadach wolę mieć dane coś jako statyczna referencje w innej klasie przez co moja klasa nie ma wspomnianych dwóch odpowiedzialności. W normalnym języku użyłbym po prostu globala

Tak czy owak w tym przypadku nie mówimy o singletonie np. takich strumeni mogę mieć kilka. To co mnie najbardziej razi to połączenie logiki singletonu z samą klasą co zazwyczaj nie ma sensu

[Krolik]

@Saly: czekaj, ale to w tej sytuacji piszesz już o konkretnym języku opartym o klasy. Jeśli dopuszczasz referencje statyczna to oznacza że nie krytykujesz singletona tylko raczej krytykujesz brak wsparcia w języku takim jak Java czy C++ dla singletonów. A co jeśli język nie wymusza użycia klas do robienia singletonów? Np. object w Scala? Też złe?

[Saly]

@Krolik: statyczna referencja w INNEJ klasie. Np. System.out w javie. Chodzi mi o rozdzielenie logiki trzymania globalnej instancji i samej logiki w inne miejsce