Jak zmienić kod, aby usunąć niepotrzebne singletony?

To nie Singleton-ness jest problemem. Dobrze jest mieć obiekt, którego będzie tylko jedna instancja. Problemem jest globalny dostęp. Klasy, które używają Store, powinny otrzymać instancję Store w konstruktorze (lub mieć właściwość Store / element danych, który można ustawić) i wszystkie mogą otrzymać tę samą instancję. Store może nawet przechowywać w sobie logikę, aby zapewnić, że tylko jedna instancja została kiedykolwiek utworzona.

Mój sposób na uniknięcie singletonów wywodzi się z idei, że "application global" nie oznacza "vm global" (tj. static). Dlatego wprowadzam klasę ApplicationContext, która przechowuje dużo wcześniejszych informacji static singleton, które powinny być globalne dla aplikacji, jak np. sklep konfiguracyjny. Kontekst ten jest przekazywany do wszystkich struktur. Jeśli używasz dowolnego menedżera kontenerów lub usług IOC, możesz użyć tego, aby uzyskać dostęp do kontekstu.

Nie ma nic złego w używaniu globalnego lub Singletona w twoim programie. Nie pozwól, żeby ktoś cię dogmatyzował. Zasady i wzorce to miłe Zasady. Ale w końcu to twój projekt i powinieneś sam Oceniać, jak radzić sobie z sytuacjami związanymi z globalnymi danymi.

Nieograniczone korzystanie z globali to zła wiadomość. Ale tak długo, jak jesteś sumienny, nie zabiją twojego projektu. Niektóre obiekty w systemie zasługują na singleton. Na standardowe wejścia i wyjścia. Twój system logowania. W grze, grafiki, dźwięku i podsystemów wejściowych, a także bazy danych podmiotów gry. W GUI, okna i główne komponenty panelu. Twoje dane konfiguracyjne, menedżer wtyczek, dane serwera www. Wszystkie te rzeczy są mniej lub bardziej globalne dla Twojej aplikacji. Myślę, że twoja klasa również by się na to zdała.

Jest jasne, jaki jest koszt korzystania z globali. Każda część aplikacji może ją modyfikować. Namierzanie błędów jest trudne, gdy każda linia kodu jest podejrzana w śledztwie.

Ale co z kosztem nieużywania globali? Jak Wszystko inne w programowaniu, to kompromis. Jeśli unikniesz używania globali, będziesz musiał przekazać te stateful objects jako parametry funkcji. Alternatywnie, możesz przekazać je do konstruktora i zapisać jako zmienną członkowską. Gdy masz wiele takich obiektów, sytuacja się pogarsza. Jesteś teraz threading twój stan. W niektórych sprawy, to nie problem. Jeśli wiesz, że tylko dwie lub trzy funkcje muszą obsłużyć ten Stanowy obiekt Store, jest to lepsze rozwiązanie.

Ale w praktyce nie zawsze tak jest. Jeśli każda część aplikacji dotknie twojego sklepu, będziesz gwintować go do kilkunastu funkcji. Ponadto niektóre z tych funkcji mogą mieć skomplikowaną logikę biznesową. Kiedy przełamujesz tę logikę biznesową z funkcjami pomocniczymi, musisz -- wątek swój stan trochę więcej! Powiedzmy na przykład, że zdajesz sobie sprawę że głęboko zagnieżdżona funkcja potrzebuje pewnych danych konfiguracyjnych z obiektu Store. Nagle musisz edytować 3 lub 4 deklaracje funkcji, aby uwzględnić parametr store. Następnie musisz wrócić i dodać sklep jako rzeczywisty parametr wszędzie, gdzie zostanie wywołana jedna z tych funkcji. Może być tak, że jedynym zastosowaniem funkcji dla sklepu jest przekazanie jej do jakiejś podfunkcji, która jej potrzebuje.

Wzory to tylko Zasady. Czy Ty Zawsze używaj kierunkowskazów przed dokonaniem zmiana pasa w samochodzie? Jeśli jesteś przeciętną osobą, zazwyczaj przestrzegasz zasady, ale jeśli jedziesz o 4 nad ranem pustą drogą, kogo to obchodzi, prawda? Czasami ugryzie cię w tyłek, ale to zarządzane ryzyko.

Jeśli chodzi o Twój zawyżony problem wywołania konstruktora, możesz wprowadzić klasy parametrów lub metody fabryczne, aby wykorzystać ten problem.

A Klasa parametru przenosi część danych parametru do własnej klasy, np. tak:

var parameterClass1 = new MenuParameter(menuBar, editor);
var parameterClass2 = new StuffParameters(sasquatch, ...);

var ctrl = new MyControllerClass(managedStore, parameterClass1, parameterClass2);

Afactory method jest metodą, która tworzy wszystkie instancje klasy i ma tę zaletę, że hermetyzuje tworzenie wspomnianych obiektów. Są również dość łatwe do refaktorowania z Singletona, ponieważ są podobne do metod getInstance, które widzisz we wzorach Singletona. Załóżmy, że mamy następujący przykład prostego singletonu bez wątków:

// The Rather Unfortunate Singleton Class
public class SingletonStore {
    private static SingletonStore _singleton
        = new MyUnfortunateSingleton();

    private SingletonStore() {
        // Do some privatised constructing in here...
    }

    public static SingletonStore getInstance() {
        return _singleton;
    }  

    // Some methods and stuff to be down here
}

// Usage: 
// var singleInstanceOfStore = SingletonStore.getInstance();

Łatwo jest refakturować to w kierunku metoda fabryczna. Rozwiązaniem jest usunięcie odniesienia statycznego:

public class StoreWithFactory {

    public StoreWithFactory() {
        // If the constructor is private or public doesn't matter
        // unless you do TDD, in which you need to have a public 
        // constructor to create the object so you can test it.
    }

    // The method returning an instance of Singleton is now a
    // factory method. 
    public static StoreWithFactory getInstance() {
        return new StoreWithFactory(); 
    }
}

// Usage:
// var myStore = StoreWithFactory.getInstance();

Użycie jest nadal takie samo, ale nie jesteś ugrzęzły z posiadania jednej instancji. Oczywiście przeniesiesz tę metodę fabryczną do własnej klasy, ponieważ klasa Store nie powinna zajmować się tworzeniem samej siebie (i przypadkowo podąża za zasadą jednej odpowiedzialności jako efekt przeniesienia metody fabrycznej).

Dobra, po pierwsze, pojęcie "singletony są zawsze złe" jest złe. Używasz Singletona, gdy masz zasób, który nie będzie lub nie może być duplikowany. Nie ma sprawy.

To powiedziawszy, w twoim przykładzie, jest oczywisty stopień swobody w aplikacji: ktoś mógłby przyjść i powiedzieć " ale chcę {3]} dwa {4]} sklepy."

Istnieje kilka rozwiązań. Tym, który występuje przede wszystkim jest zbudowanie klasy fabrycznej; gdy poprosisz o sklep, daje Ci jeden o nazwie z jakąś uniwersalną nazwą (np. URI.) Wewnątrz tego sklepu, musisz mieć pewność, że wiele kopii nie nadepnie na siebie, poprzez krytyczne regiony lub jakąś metodę zapewnienia atomiczności transakcji.

Miško Hevery ma ładną serię artykułów na temat testowalności, między innymi singleton , gdzie mówi nie tylko o problemach, ale także o tym, jak można je rozwiązać (patrz "naprawianie wady").

Lubię zachęcać do używania singletonów tam, gdzie jest to konieczne, zniechęcając jednocześnie do używania wzoru Singletona. Zwróć uwagę na różnicę w przypadku tego słowa. Singleton (małe litery) jest używany wszędzie tam, gdzie potrzebujesz tylko jednej instancji czegoś. Jest on tworzony na początku programu i przekazywany konstruktorowi klas, które go potrzebują.

class Log
{
  void logmessage(...)
  { // do some stuff
  }
};

int main()
{
  Log log;

  // do some more stuff
}

class Database
{
  Log &_log;
  Database(Log &log) : _log(log) {}
  void Open(...)
  {
    _log.logmessage(whatever);
  }
};

Użycie Singletona daje wszystkie możliwości anty-pattern Singletona, ale sprawia, że kod jest łatwiejszy do rozszerzenia, i sprawia, że jest testowalny(w znaczeniu słowa zdefiniowanego na blogu Google testing). Na przykład, możemy zdecydować, że potrzebujemy zdolność do logowania się do usługi internetowej w niektórych momentach, jak również, używając singleton możemy łatwo to zrobić bez znaczących zmian w kodzie.

Dla porównania, wzór Singletona jest inną nazwą zmiennej globalnej. Nigdy nie jest używany w kodzie produkcyjnym.