Сводная версия:
Вы знаете, как часто вы используете глобалы? Хорошо, теперь используйте Singletons даже меньше. Гораздо меньше на самом деле. Почти никогда. Они разделяют все проблемы, которые глобальные проблемы имеют со скрытой связью (напрямую влияющей на тестируемость и ремонтопригодность), и часто ограничение «только один может существовать» на самом деле является ошибочным предположением.
Подробный ответ:
Самая важная вещь, которую нужно понять о синглтоне, это то, что это глобальное состояние. Это шаблон для выставления единственного экземпляра глобально не пропущенного доступа . Это имеет все проблемы в программировании, которые имеют глобальные переменные, но также принимает некоторые интересные новые детали реализации и, в остальном, очень мало реальной ценности (или, действительно, это может привести к ненужным дополнительным затратам с аспектом одного экземпляра). Реализация настолько отличается, что люди часто ошибочно принимают его за объектно-ориентированный метод инкапсуляции, когда он на самом деле представляет собой просто необычный глобальный экземпляр.
Единственная ситуация, в которой вы должны учитывать синглтон, - это когда более одного экземпляра уже глобальных данных фактически является ошибкой логического или аппаратного доступа. Даже тогда вы, как правило, не должны иметь дело с синглтоном напрямую, а вместо этого должны предоставить интерфейс-оболочку, для которого можно создавать экземпляры столько раз, сколько вам нужно, но только для доступа к глобальному состоянию. Таким образом, вы можете продолжать использовать внедрение зависимостей , и если вы когда-нибудь сможете отключить глобальное состояние от поведения класса, это не будет значительным изменением в вашей системе.
Однако при этом возникают тонкие проблемы, когда кажется, что вы полагаетесь не на глобальные данные, а на вас. Так что (используя внедрение зависимостей интерфейса, который обертывает синглтон), это всего лишь предложение, а не правило. В целом это все же лучше, потому что, по крайней мере, вы можете видеть, что класс опирается на синглтон, тогда как простое использование функции :: instance () внутри живота функции-члена класса скрывает эту зависимость. Он также позволяет вам извлекать классы, основанные на глобальном состоянии, и улучшать модульные тесты для них, и вы можете передавать в фиктивные объекты, которые ничего не делают, где, если вы испечете зависимость от синглтона прямо в класс это НАМНОГО сложнее.
При выпечке одиночного :: instance вызова, который также создает себя в классе, вы делаете наследование невозможным . Обходные пути обычно разрушают часть «одного экземпляра» одиночного файла. Рассмотрим ситуацию, когда у вас есть несколько проектов, использующих общий код в классе NetworkManager. Даже если вы хотите, чтобы этот NetworkManager был глобальным состоянием и единичным экземпляром, вы должны очень скептически относиться к превращению его в единый объект. Создавая простой синглтон, который создает себя, вы фактически лишаете возможности любого другого проекта наследовать этот класс.
Многие считают ServiceLocator анти-паттерном, однако я считаю, что он на полшага лучше, чем Singleton, и эффективно затмевает цель паттерна Go4. Существует много способов реализации локатора служб, но основная концепция заключается в том, что вы разбиваете конструкцию объекта и доступ к нему на два этапа. Таким образом, во время выполнения вы можете подключить соответствующую производную службу, а затем получить к ней доступ из единой глобальной точки контакта. Это имеет преимущество явного порядка построения объектов, а также позволяет вам выводить из вашего базового объекта. Это все еще плохо по большинству заявленных причин, но это на меньше плохо, чем синглтон и является заменой.
Один конкретный пример приемлемого синглтона (читай: servicelocator) может заключаться в обертывании интерфейса стиля c одного экземпляра, такого как SDL_mixer. Один пример синглтона, который часто наивно реализуется там, где его, вероятно, не должно быть, находится в классе журналирования (что происходит, когда вы хотите войти в консоль И на диск? Или если вы хотите регистрировать подсистемы отдельно.)
Однако наиболее важные проблемы, связанные с глобальным состоянием, всегда возникают, когда вы пытаетесь реализовать правильное модульное тестирование (и вы должны пытаться это сделать тот). С вашим приложением становится намного сложнее работать, когда недра классов, к которым вы на самом деле не имеете доступа, пытаются выполнять запись и чтение на жестком диске, подключаться к работающим серверам и отправлять реальные данные или воспроизводить звук из ваших динамиков. Вилли Нилли. НАМНОГО, гораздо лучше использовать внедрение зависимостей, чтобы вы могли смоделировать класс бездействия (и увидеть, что вам нужно сделать это в конструкторе классов) в случае плана тестирования и указать на это без необходимости гадать все глобальное состояние, от которого зависит ваш класс.
Ссылки по теме:
Использование шаблона против появления
Шаблоны полезны в качестве идей и терминов, но, к сожалению, люди, похоже, чувствуют необходимость «использовать» шаблон, когда действительно шаблоны реализуются в соответствии с потребностями. Часто синглтон специально включается просто потому, что это часто обсуждаемая модель. Проектируйте свою систему с учетом шаблонов, но не проектируйте свою систему специально для того, чтобы сгибаться к ним только потому, что они существуют. Это полезные концептуальные инструменты, но так же, как вы не используете каждый инструмент в наборе инструментов только потому, что можете, вы не должны делать то же самое с шаблонами. Используйте их по мере необходимости и не более или менее.
Пример сервисного локатора для одного экземпляра
#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;
}