При каких обстоятельствах я должен использовать класс Singleton?

Question

Закрыт как точный дубликат этого вопроса . Но вновь открыт, так как другие вопросы Singleton предназначены для общего пользования, а не для доступа к БД

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

Какова цель создания таких классов, чтобы они все-таки были синглетонами?
Требуется ли последовательный доступ к базе данных, что не является убедительным, поскольку большинство современных баз данных могут хорошо справляться с параллелизмом?
Это возможность многократно использовать одно соединение, о котором можно было бы заботиться через пул соединений? Или это экономит память, запуская один экземпляр?

Пожалуйста, просветите меня об этом.

Answer 1

Вы, вероятно, не захотите использовать Синглтон для описанных вами обстоятельств. Наличие всех подключений к БД через один экземпляр класса типа DBD / DBI серьезно снизит производительность вашего запроса.

НТН

ура

Rob

Answer 2

Из " Шаблоны проектирования: элементы многоразового объектно-ориентированного программного обеспечения ":

Для некоторых классов важно У меня ровно один экземпляр. Хотя может быть много принтеров в система, должна быть только одна спулер принтера. Там должно быть только одна файловая система и одно окно менеджер. ...

Используйте шаблон Singleton, когда:

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

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

Answer 3

Я обнаружил, что шаблон синглтона подходит для класса, который:

• Не имеет состояния
• Полон базовых "участников обслуживания"
• Надо жестко контролировать свои ресурсы.

Примером этого может быть класс доступа к данным.

У вас были бы методы, которые принимают параметры и возвращают, скажем, DataReader, но вы не манипулируете состоянием считывателя в синглтоне, вы просто получаете его и возвращаете.

В то же время вы можете взять логику, которая может быть распределена по вашему проекту (для доступа к данным), и интегрировать ее в единый класс, который правильно управляет своими ресурсами (соединениями с базой данных), независимо от того, кто его вызывает. *

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

Answer 4

Этот вопрос был задан, прежде чем я думаю. Взгляните здесь

Смотри этот вопрос:
На шаблонах проектирования: когда использовать Singleton?

Answer 5

Если у класса есть нет состояния, нет смысла делать его одиночным; все языки с хорошим поведением будут создавать не более одного указателя на векторную таблицу (или эквивалентную структуру) для отправки методов.

Если существует состояние экземпляра, которое может варьироваться среди экземпляров класса, то шаблон синглтона не будет работать; вам нужно более одного экземпляра.

Из этого следует, что из-за исчерпания, единственные случаи, когда следует использовать Singleton, это когда существует состояние, которое должно быть общим для всех средств доступа, и только состояние, которое должно быть общим для всех средств доступа.

Есть несколько вещей, которые могут привести к чему-то вроде синглтона:

• Фабричный образец: вы строите и вернуть объект, используя некоторые общее состояние.
• Пулы ресурсов: у вас есть общий доступ таблица некоторых ограниченных ресурсов, как соединения с базой данных, что вы должен управлять среди большой группы пользователи. (Бампо-версия - это где одно соединение с БД удерживается синглтон.)
• Параллельное управление внешним ресурс; семафор обычно будет вариант синглтона, потому что операции P / V должны атомно изменить общий счетчик.

Answer 6

В качестве одного примера, объектные фабрики очень часто являются хорошими кандидатами на роль одиноких.

Answer 7

У вас есть слой репозитория, который вы хотите создать один раз, и эта ссылка используется везде.

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

Мой совет:

1. Найдите понравившийся IOC и интегрируйте его в свое приложение (StructureMap, Unity, Spring.Net, Castle Windsor, Autofac, Ninject ... выберите один).
2. Реализация интерфейса для вашего хранилища.
3. Скажите IOC, что следует обращаться с хранилищем как синглтоном и возвращать его, когда интерфейс запрашивает хранилище через интерфейс.
4. Узнайте о внедрении зависимости.

Это большой труд для простого вопроса. Но тебе будет лучше.

Answer 8

Модель Singleton потеряла большую часть своего блеска в последние годы, в основном из-за роста юнит-тестирования.

Синглтоны могут сделать модульное тестирование очень трудным - если вы можете когда-либо создать только один экземпляр, как вы можете написать тесты, которые требуют «свежих» экземпляров тестируемого объекта? Если один тест каким-либо образом изменяет этот синглтон, любые дальнейшие тесты с тем же объектом на самом деле не начинаются с чистого листа.

Синглтоны также проблематичны, потому что они фактически являются глобальными переменными. У нас была проблема с многопоточностью несколько недель назад в моем офисе из-за глобализации Singleton, который изменялся из разных потоков; разработчик был ослеплен использованием санкционированного «шаблона», не понимая, что то, что он действительно создает, является глобальной переменной.

Другая проблема заключается в том, что в определенных ситуациях может быть патологически сложно создавать настоящие синглтоны. Например, в Java можно создать несколько экземпляров «синглтона», если вы неправильно реализуете метод readResolve() для сериализуемых классов.

Вместо создания Singleton рассмотрите возможность предоставления статического фабричного метода, который возвращает экземпляр; это, по крайней мере, дает вам возможность передумать, не нарушая своего API.

Джош Блох хорошо обсуждает это в Effective Java .

Answer 9

1. использование синглтона здесь на самом деле ничего не дает, но ограничивает гибкость
2. ВЫ ХОТИТЕ параллелизм или не будете масштабировать
3. беспокойство о соединениях и памяти здесь преждевременная оптимизация

Answer 10

Singleton - это полезный шаблон проектирования, позволяющий использовать только один экземпляр вашего класса. Цель Singleton - контролировать создание объектов, ограничивая число до одного, но позволяя гибко создавать больше объектов в случае изменения ситуации. Поскольку существует только один экземпляр Singleton, любые поля экземпляра Singleton будут появляться только один раз на класс, как статические поля.

Источник: java.sun.com