Kiedy nie należy stosować wzoru Singletona? (Poza oczywistym)

Wersja Skrócona:

Szczegółowa Odpowiedź:

Najważniejszą rzeczą do uświadomienia sobie o singletonie jest to, że jest to stan globalny. Jest to wzór do ujawnienia pojedynczej instancji globalnie nieograniczonego dostępu . Ma to wszystkie problemy w programowaniu, które mają globalni, ale także przyjmuje kilka interesujących nowych szczegółów implementacji i poza tym bardzo małą rzeczywistą wartość (lub, w rzeczywistości, może to przynieść niepotrzebne dodatkowe koszty z aspektem pojedynczej instancji). Implementacja jest na tyle Inna, że ludzie często mylą ją z obiektową metodą enkapsulacji, gdy tak naprawdę jest to tylko fantazyjna pojedyncza instancja global.

Jedyną sytuacją, w której powinieneś rozważyć singleton, jest sytuacja, w której posiadanie więcej niż jednej instancji już globalnych danych byłoby w rzeczywistości logicznym lub sprzętowym błędem dostępu. Nawet wtedy zazwyczaj nie powinieneś zajmować się singletonem bezpośrednio, ale zamiast tego dostarczaj interfejs wrappera, który jest dozwolony do tworzenia instancji tyle razy, ile potrzebujesz, ale tylko uzyskuje dostęp do stanu globalnego. W ten sposób można nadal używać zależność wstrzyknięcie a jeśli kiedykolwiek możesz usunąć stan Globalny z zachowania klasy, nie jest to wielka zmiana w całym systemie.

Istnieją subtelne problemy z tym, jednak, gdy wydaje się, że nie polegasz na danych globalnych, ale jesteś. Tak, że (używając dependency injection interfejsu, który zawija singleton) jest tylko sugestią, a nie regułą. Ogólnie jest jeszcze lepiej, bo przynajmniej widać, że Klasa opiera się na singleton natomiast samo użycie funkcji:: instance () wewnątrz brzucha funkcji członka klasy ukrywa tę zależność. Pozwala również na wyodrębnianie klas opartych na stanie globalnym i ulepszanie testy jednostkowe dla nich, i można przekazać w mock do-nothing obiektów, gdzie jeśli piec poleganie na singleton bezpośrednio do klasy jest to o wiele trudniejsze.

Podczas pieczenia singleton :: instancja wywołanie, które również tworzy instancję do klasy you uniemożliwiadziedziczenie . Work-arounds zazwyczaj łamie "pojedynczą instancję" część singletonu. Rozważ sytuację, w której masz wiele projektów opartych na współdzielonym kodzie w klasie NetworkManager. Nawet jeśli chcesz, aby ten NetworkManager był stanem globalnym i pojedynczą instancją, powinieneś być Bardzo sceptycznie nastawiony do przekształcenia go w singleton. Tworząc prosty singleton, który tworzy instancje, w zasadzie uniemożliwiasz uzyskanie jakiegokolwiek innego projektu z tej klasy.

Wielu uważa, że ServiceLocator jest anty-wzorem, jednak uważam, że jest o pół kroku lepszy niż Singleton i skutecznie przyćmiewa cel wzoru Go4. Istnieje wiele sposobów wdrożenia lokalizatora usług, ale podstawowa koncepcja polega na rozbiciu konstrukcji obiektu i dostępu do obiektu na dwa etapy. W ten sposób podczas wykonywania można podłączyć odpowiednią usługę pochodną, a następnie uzyskać do niej dostęp z jednego globalny punkt kontaktowy. Ma to zaletę wyraźnego zlecenia budowy obiektów, a także pozwala na wyprowadzenie z obiektu podstawowego. To jest nadal źle z większości podanych powodów, ale jest Mniej źle niż Singleton i jest zamiennikiem drop-in.

Jeden konkretny przykład akceptowalnego Singletona (Czytaj: servicelocator) może być w zawijaniu interfejsu w stylu c, takiego jak SDL_mixer. Jednym z przykładów singletonu często naiwnie realizowanego, gdzie prawdopodobnie nie powinno być w klasie logowania (co się dzieje, gdy chcesz się zalogować na konsolę i na dysk? Lub jeśli chcesz logować podsystemy oddzielnie.)

Najważniejsze problemy polegania na państwie globalnym, jednak prawie zawsze pojawiają się, gdy próbujesz wdrożyć właściwe testy jednostkowe (i powinieneś próbować to zrobić). O wiele trudniej jest poradzić sobie z aplikacją, gdy wnętrzności klas, do których tak naprawdę nie masz dostępu, próbują aby wykonać nieograniczony zapis i odczyt dysku, połącz się z serwerami na żywo i wyślij prawdziwe dane lub wydmuchaj dźwięk z głośników willy nilly. O wiele, wiele lepiej jest użyć dependency injection, aby móc stworzyć klasę do-nothing (i zobaczyć, że musisz to zrobić w konstruktorze klasy) w przypadku planu testowego i wskazać na to bez konieczności opisywania całego globalnego stanu, od którego zależy Twoja klasa.

Powiązane Linki:

• kruchość wywołana przez państwo Globalne i Singletony
• Dependency Injection to Avoid Singletons
• fabryki i Singletony

Użycie wzorca a pojawienie się

Wzory są przydatne jako pomysły i terminy, ale niestety ludzie wydają się odczuwać potrzebę" używania " wzorca, gdy naprawdę wzorce są implementowane zgodnie z potrzebami. Często singleton specjalnie jest shoehorned w po prostu dlatego, że jest to powszechnie omawiany wzór. Zaprojektuj Swój system z świadomość wzorców, ale nie projektuj swojego systemu specjalnie po to, aby się do nich ugiąć tylko dlatego, że istnieją. Są użytecznymi narzędziami koncepcyjnymi, ale tak jak nie używasz każdego narzędzia w zestawie narzędzi tylko dlatego, że możesz, nie powinieneś robić tego samego z wzorami. Używaj ich w razie potrzeby i nie mniej lub bardziej.

Przykładowy Lokalizator Usług Dla Jednej Instancji

#include <iostream>
#include <assert.h>

class Service {
public:
    static Service* Instance(){
        return _instance;
    }
    static Service* Connect(){
        assert(_instance == nullptr);
        _instance = new Service();
    }
    virtual ~Service(){}

    int GetData() const{
        return i;
    }
protected:
    Service(){}
    static Service* _instance;
    int i = 0;
};

class ServiceDerived : public Service {
public:
    static ServiceDerived* Instance(){
        return dynamic_cast<ServiceDerived*>(_instance);
    }
    static ServiceDerived* Connect(){
        assert(_instance == nullptr);
        _instance = new ServiceDerived();
    }
protected:
    ServiceDerived(){i = 10;}
};

Service* Service::_instance = nullptr;

int main() {
    //Swap which is Connected to test it out.
    Service::Connect();
    //ServiceDerived::Connect();
    std::cout << Service::Instance()->GetData() << "\n" << ((ServiceDerived::Instance())? ServiceDerived::Instance()->GetData() :-1);
    return 0;
}