Зачем нужен Синглтон?

[Raskolnikov]

Не могу никак понять, зачем нужен паттерн Синглтон
Допустим нужен мне единственный экземпляр класса для подключения к бд. Я могу создать этот экземпляр в одном месте, а затем импортировать туда куда нужно. И зачем мне этот Синглтон, при каких обстоятельствах его использовать?

 

[j0ker13]

Синглтон гарантирует что будет только один экземпляр, в случае базы данных, что будет только 1 подключение.

 

[Raskolnikov]

Синглтон гарантирует что будет только один экземпляр, в случае базы данных, что будет только 1 подключение.

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

 

[pewpewpew]

Если ты импортируешь экземпляр, то ты говнокодер. А синглтон не даёт тебе дублировать свой говнокод в памяти.
И да, это давно антипаттерн

 

[Nosferatu]

Вообще синглтон не рекомендуют использовать взрослые дяди.
На него набрасываются и не замечают его недостатков, из коих:
1. Синглтон нарушает SRP (Single Responsibility Principle) — класс синглтона, помимо того чтобы выполнять свои непосредственные обязанности, занимается еще и контролированием количества своих экземпляров.
2. Глобальное состояние. Про вред глобальных переменных вроде бы уже все знают, но тут та же самая проблема. Когда мы получаем доступ к экземпляру класса, мы не знаем текущее состояние этого класса, и кто и когда его менял, и это состояние может быть вовсе не таким, как ожидается. Иными словами, корректность работы с синглтоном зависит от порядка обращений к нему, что вызывает неявную зависимость подсистем друг от друга и, как следствие, серьезно усложняет разработку.
3. Зависимость обычного класса от синглтона не видна в публичном контракте класса. Так как обычно экземпляр синглтона не передается в параметрах метода, а получается напрямую, через GetInstance(), то для выявления зависимости класса от синглтона надо залезть в тело каждого метода — просто просмотреть публичный контракт объекта недостаточно.
4. Наличие синглтона понижает тестируемость приложения в целом и классов, которые используют синглтон, в частности. Во-первых, вместо синглтона нельзя подпихнуть Mock-объект, а во-вторых, если синглтон имеет интерфейс для изменения своего состояния, то тесты начинают зависеть друг от друга.
Говоря же проще — синглтон повышает связность, и все вышеперечисленное, в том или ином виде, есть следствие повышения связности.

 

[Nosferatu]

Синглтон гарантирует что будет только один экземпляр, в случае базы данных, что будет только 1 подключение.

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

 

[Nosferatu]

каноничный пример:
import sqlite3

class MetaSingleton(type):
_instances = {}
def __call__(cls, *args, **kwargs):
if cls not in cls._instances:
cls._instances[cls] = super(MetaSingleton, cls).__call__(*args, **kwargs)
return cls._instances[cls]

class Database(metaclass=MetaSingleton):
connection = None

def connect(self):
if self.connection is None:
self.connection = sqlite3.connect("db.sqlite3")
self.cursorobj = self.connection.cursor()
return self.cursorobj


db1 = Database().connect()
db2 = Database().connect()
print ("Database Objects DB1", db1)
print ("Database Objects DB2", db2)



этот код неплохо работает для одной базы - но ни хрена не работает для кластера.