Есть ли случаи, когда синглтон является лучшим вариантом?

Question

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

Примером, где я думаю, что синглтон является лучшим вариантом, является реализация Identity Map , где вам нужно отслеживать все модели, которые уже были загружены из базы данных в вашем слое отображения. В этом случае важно, чтобы карта была действительно глобальной, чтобы весь клиентский код использовал один и тот же экземпляр карты, и все они обращались к одному и тому же списку загруженных моделей. Кажется, самое простое решение - реализовать класс как одноэлементный (или как статический метод). Это лучший подход или есть другой способ?

Есть ли другие случаи, когда можно использовать синглтон или они всегда плохие?

Answer 1

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

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

Answer 2

См. эту тему .

Answer 3

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

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

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

2) Многие применения Singleton могут быть заменены классом со всеми статическими методами и данными. Если вы можете сделать это без потери производительности, сделайте это.

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

Answer 4

Моя личная рекомендация - никогда не кодировать класс как одиночный, если впоследствии вы можете просто создать экземпляр одного объекта класса. Это делает синглтоны очень редкими и часто ненужными в коде приложения. Это особенно верно при использовании DI-фреймворков, таких как Spring.

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

Answer 5

Одиночные логики имеют смысл, когда вы используете веб-программирование: вам обычно нужен только один экземпляр класса вывода страницы для каждого запроса и один пользовательский объект для него. Базы данных отличаются, хотя - реализация разделения привилегий является хорошей причиной для того, чтобы хотеть больше чем один объект БД.

Answer 6

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

Вот небольшая защита паттерна синглтона.

Иногда программе необходимо представлять или взаимодействовать с чем-то действительно уникальным. Примером является физический ресурс. Например, вы не можете иметь более одного «стандартного выхода». И представление процесса ОС (например, Мидлет J2ME).

Синглтоны, как при использовании класса / интерфейса для инкапсуляции, и такие преимущества того, что иначе было бы голой глобальной переменной, того стоит.

Answer 7

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

Answer 8

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

• Comparer<T>.Default - обеспечивает IComparer<T> реализацию для сортировки T
• EqualityComparer<T>.Default - предоставляет IEqualityComparer<T> реализацию для хеширования / проверки на равенство T

Это как средство для достижения цели; это не то, что мы пытаемся сделать, просто разумное «как».

Что касается примера «карты идентичности», лично я предпочел бы оставить это в экземпляре и сделать этот экземпляр доступным для всего моего кода. Помимо всего прочего, это помогает тестированию, если вы можете отказаться от карты между тестами или иметь возможность (позже) иметь несколько карт идентичности одновременно.