Это - по общему признанию довольно свободный вопрос. Мое текущее понимание одиночных элементов - то, что они - класс, который Вы настраиваете таким способом, которым когда-либо создается только один экземпляр.
Это много походит на статический класс мне. Так как основное различие - это со статическим классом, Вы не делаете / не может инстанцировать его, Вы просто используете его такой как Math.pi()
. С singleton-классом необходимо было бы все еще сделать что-то как
singleton firstSingleton = new singleton();
firstSingleton.set_name("foo");
singleton secondSingleton = new singleton();
Исправьте меня, если я неправ, но firstSingleton == secondSingleton
прямо сейчас, да?
secondSingleston.set_name("bar");
firstSingleton.report_name(); // will output "bar" won't it?
Отметьте, я спрашиваю этот язык независимо, больше о понятии. Таким образом, я не волнуюсь по поводу на самом деле, как кодировать такой класс, но больше почему Вы были бы wan't к и какую вещь необходимо будет рассмотреть.
Основное преимущество синглтона перед классом, состоящим из статики, заключается в том, что позже вы можете легко решить, что вам действительно нужно более одного экземпляра, например по одному на поток.
Однако на практике основная цель синглтонов - заставить людей меньше думать о глобальных переменных.
Практический пример хорошего использования синглтона: у вас есть приложение, использующее базу данных SQL, и вам нужен пул соединений. Цель такого пула - повторно использовать соединение с БД, поэтому вы определенно хотите, чтобы все клиенты использовали один и тот же пул. Таким образом, использование синглтона - правильный дизайн. Но однажды вам понадобится приложение для подключения к второму серверу БД, и вы поймете, что у вас не может быть подключений к разным серверам в одном пуле. Таким образом, ваш синглтон «всего один экземпляр» становится «одним экземпляром на сервер БД».
Синглтоны в основном полезны, когда вам нужен интерфейс для одноэлементной службы, но вы не знаете до времени выполнения, какой конкретный класс будет создан.
Например, вы можете захотеть объявить центральную службу ведения журнала, но только во время выполнения решите, подключать ли средство ведения журнала файлов, средство ведения журнала заглушек, средство ведения журнала базы данных или средство ведения журнала очереди сообщений.
В дополнение к другим ответам я должен сказать, что синглтоны могут помочь вам, когда вы хотите статический класс, но не можете его иметь, потому что из-за дизайна вашего приложения оно будет наследовать экземпляр класса.
Не во всех языках есть «статические классы» (например, в C ++ их нет).
Опять же, в примере C ++, добавление статических переменных в класс - проблема, потому что вам нужно поместить их как в заголовок, так и в файл .cpp, поэтому синглтон в этом случае очень полезен.
Каждый язык индивидуален. Я полагаю, что в C # они не очень полезны (и на самом деле, насколько я знаю, они используются не очень часто)
Есть два способа использования синглтонов.
почему вы не захотите
Я не захочу, потому что синглтоны обычно очень плохой способ решения ваших проблем. Я рекомендую вам полностью избегать их.
Основные причины:
Я предлагаю вам почитать остальное (включая подробные объяснения) в блоге этого сотрудника Google:
Как уже говорили другие:
Обратите внимание, что, на мой взгляд, "статические классы" обычно также плохая идея, хакерское обходное решение для языка, который не позволяет свободные функции, или для обмена состоянием между кучей функций без необходимости передавать это состояние в качестве параметра.
По моему опыту, почти все конструкции с синглтонами или статическими классами можно превратить в нечто лучшее, более понятное и гибкое, избавившись от этих конструкций.
Редактировать: По просьбе, почему большинство синглтонов - это глобальные переменные под другим названием.
В большинстве языков, которые я знаю, доступ к большинству классов синглтонов осуществляется через статическую функцию-член этого класса. Единственный экземпляр доступен для всего кода, который имеет доступ к определению класса синглтона. Это глобальная переменная - весь код, включающий класс, может вносить изменения в единственный экземпляр вашего синглтона.
Если вы не используете статическую функцию-член (или какой-либо статический метод фабрики, который имеет те же последствия), а вместо этого передаете объект синглтона всем клиентам, которым он нужен, то у вас нет необходимости в паттерне синглтона, просто передавайте один и тот же объект всем клиентам.
Немного знаний - опасная вещь, а одиночки - опасные существа. В дополнение к написанному выше, я могу подчеркнуть, что управление объектами Singleton в течение всего срока службы также важно. В рамках ACE это успешно обрабатывается. Вы можете найти этот документ здесь: http://www.cs.wustl.edu/~schmidt/PDF/ObjMan.pdf
Также обратите внимание, что одиночные классы не должны быть копируемыми классами. Этот шаблон может показаться самым простым, но, наоборот, одним из самых сложных. Поэтому я спрашиваю кандидатов об этом зле в синглтонах.