Как мне провести рефакторинг моего кода, чтобы удалить ненужные синглтоны?

Внедрение зависимостей - ваш друг.

Взгляните на эти сообщения в отличном блоге по тестированию Google:

• Синглтоны - патологические лжецы (но вы, вероятно, уже понимаете это, если вы задаете этот вопрос)
• Обсуждение внедрения зависимостей
• Руководство по написанию тестируемого кода

Надеюсь, кто-то создал фреймворк / контейнер DI для мира C ++? Похоже, Google выпустил платформу тестирования C ++ и C ++ Mocking Framework, который может вам помочь.

Проблема не в единственности. Хорошо иметь объект, экземпляр которого может существовать только один раз. Проблема в глобальном доступе. Ваши классы, использующие Store, должны получить экземпляр Store в конструкторе (или иметь свойство / элемент данных Store, который можно задать), и все они могут получить один и тот же экземпляр. Магазин может даже хранить в себе логику, чтобы гарантировать, что когда-либо будет создан только один экземпляр.

Мой способ избежать синглтонов основан на идее, что «глобальное приложение» не означает «глобальное виртуальное устройство» (т.е. static). Поэтому я представляю ApplicationContext класс, который содержит большую часть прежней static синглтонной информации, которая должна быть глобальной для приложения, например, хранилище конфигурации. Этот контекст передается во все структуры. Если вы используете какой-либо контейнер IOC или диспетчер служб, вы можете использовать его для доступа к контексту.

Нет ничего плохого в использовании в вашей программе глобального или синглтона. Не позволяйте никому относиться к вам категорически по поводу такого рода дерьма. Правила и шаблоны - это хорошие практические правила. Но, в конце концов, это ваш проект, и вы должны сами делать выводы о том, как справляться с ситуациями, связанными с глобальными данными.

Безудержное использование глобальных переменных - плохая новость. Но пока вы прилежны, они не убьют ваш проект. Некоторые объекты в системе заслуживают того, чтобы быть одиночными. Стандартный ввод и вывод. Ваша система журналов. В игре ваша графика, звук и подсистемы ввода, а также база данных игровых объектов. В графическом интерфейсе - ваше окно и основные компоненты панели. Ваши данные конфигурации, ваш менеджер плагинов, данные вашего веб-сервера. Все эти вещи более или менее глобальны для вашего приложения. Я думаю, что ваш класс Store тоже подойдет.

Понятно, какова стоимость использования глобалов. Любая часть вашего приложения может изменять его. Отслеживать ошибки сложно, когда каждая строчка кода является подозреваемой в расследовании.

Но как насчет стоимости НЕ использования глобальных переменных? Как и все остальное в программировании, это компромисс. Если вы избегаете использования глобальных переменных, вам придется передавать эти объекты с сохранением состояния в качестве параметров функции. В качестве альтернативы вы можете передать их конструктору и сохранить как переменную-член. Когда у вас есть несколько таких объектов, ситуация ухудшается. Теперь вы цепляете свое состояние. В некоторых случаях это не проблема. Если вы знаете, что только две или три функции должны обрабатывать этот объект Store с сохранением состояния, это лучшее решение.

Но на практике это не всегда так. Если каждая часть вашего приложения касается вашего Магазина, вы будете распределять его по десятку функций. Кроме того, некоторые из этих функций могут иметь сложную бизнес-логику. Когда вы нарушаете эту бизнес-логику с помощью вспомогательных функций, вам нужно еще немного перепрограммировать свое состояние! Скажем, например, вы понимаете, что глубоко вложенной функции требуются некоторые данные конфигурации из объекта Store. Внезапно вам нужно отредактировать 3 или 4 объявления функции, чтобы включить этот параметр хранилища. Затем вам нужно вернуться и добавить хранилище в качестве фактического параметра везде, где вызывается одна из этих функций. Возможно, единственное использование функции для Store - это передать ее какой-либо подфункции, которая в ней нуждается.

Паттерны - это всего лишь практические правила. Вы всегда включаете поворотники перед сменой полосы движения в машине? Если вы обычный человек, вы обычно будете следовать правилу, но если вы едете в 4 часа утра по пустой дороге, кого это волнует, верно? Иногда он укусит вас под зад, но это управляемый риск.

Что касается проблемы с вызовом раздутого конструктора, вы можете ввести классы параметров или фабричные методы, чтобы использовать эту проблему для вас.

класс параметров перемещает некоторые данные параметров в собственный класс, например нравится:

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

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

Это как бы просто перемещает проблему в другое место. Вместо этого вы можете оставить свой конструктор по хозяйству. Сохраняйте только параметры, которые важны при создании / запуске рассматриваемого класса, а все остальное делайте с помощью методов получения / установки (или свойств, если вы используете .NET).

фабричный метод - это метод, который создает все необходимые вам экземпляры класса и имеет преимущество инкапсуляции создания указанных объектов. Их также довольно легко реорганизовать в сторону от Singleton, потому что они похожи на методы getInstance, которые вы видите в шаблонах Singleton. Скажем, у нас есть следующий простой одноэлементный пример, не требующий обеспечения безопасности потоков:

// 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();

Его легко преобразовать в фабричный метод. Решение состоит в том, чтобы удалить статическую ссылку:

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();

Использование остается прежним, но вы не увязнете в одном экземпляре. Естественно, вы переместите этот фабричный метод в его собственный класс, так как класс Store не должен заниматься созданием самого себя (и по совпадению следовать принципу единой ответственности как эффект перемещения фабричного метода).

Отсюда у вас есть много вариантов, но я оставлю это в качестве упражнения для вас. Здесь легко переоценить (или перегреть) шаблоны. Мой совет - применять шаблон только тогда, когда в нем есть необходимость.

Хорошо, во-первых, представление о том, что «одиночки - всегда зло» неверно. Вы используете синглтон всякий раз, когда у вас есть ресурс, который никогда не будет или не может быть продублирован. Без проблем.

Тем не менее, в вашем примере в приложении есть очевидная степень свободы: кто-то может прийти и сказать: «Но я хочу два магазина».

Есть несколько решений. Первое, что происходит в первую очередь, - это создание фабричного класса; когда вы запрашиваете хранилище, он дает вам один с некоторым универсальным именем (например, URI). Внутри этого хранилища вы должны быть уверены, что несколько копий не наступают друг на друга через критические области или какой-либо метод обеспечение атомарности транзакций.

Мишко Хевери имеет серию хороших статей о тестируемости, среди прочего singleton, где он не только говорит о проблемы, но также и способы их решения (см. «Устранение недостатка»).

Мне нравится поощрять использование синглтонов там, где это необходимо, в то же время не рекомендую использовать шаблон синглтонов. Обратите внимание на разницу в регистре слова. Синглтон (нижний регистр) используется везде, где вам нужен только один экземпляр чего-либо. Он создается в начале вашей программы и передается конструктору классов, которым он нужен.

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);
  }
};

Использование синглтона дает все возможности антипаттерна синглтона, но делает ваш код более легко расширяемым и делает его тестируемым (в смысле слова, определенного в блоге о тестировании Google). Например, мы можем решить, что нам иногда нужна возможность входа в веб-службу, используя синглтон, мы можем легко сделать это без значительных изменений в коде.

Для сравнения, шаблон Singleton - это еще одно название глобальной переменной. Он никогда не используется в производственном коде.