Для чего нужен singleton?

Question

[Dauren S]

Для чего нужен singleton?Понятно , что для создания единственного экземпляра класса. А для чего нужен этот единственный экземпляр? Какова цель?

Answer 1

[Adamos]

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

Comments

[Dauren S]

Википедию я читал, программы создавал, просто объясните вот зачем нужен один экземпляр? Чисто по человески объясните? Какую цель оно несет? В чем выгода?

[Shockoway]

Dauren: В своё время мне тоже было непонятно для чего же конкретно может быть полезна такая конструкция. Но позже, когда я писал свою программу (личный учебный проект, ничего особенного) в один момент на меня снизошло озарение, мол "Вот оно! Точно! Мне нужен синглтон, он здесь идеально подойдет!". То же самое у меня было с рекурсией.

[Adamos]

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

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

Answer 2

[Евгений Шатунов]

В буквальном смысле синглтон призван упростить владение, инициализацию, контроль времени жизни и доступ к элементам глобального состояния программы. Эта фраза является самой важной. А важнее всего - правильно понять ее.

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

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

В качестве альтернативы синглтонам пропагандируются два других подхода: Registry / Service locator и Dependency injection.
К слову, все альтернативы столь же активно и все так же незаслуженно обзываются антипаттернами. :)

Теперь к примерам.
- DirectX. Для работы с графикой тебе необходимо по одной инстанции интерфейсов IDirect3D и IDirect3DDevice. Эти две инстанции декларируют глобальное состояние программы. Инстанции всех буферов, текстур, шейдеров и поверхностей создаются с использованием этих инстанций. Разумным будет предоставить доступ к инстанциям DirectX через подход синглтона.
- OpenGL старых добрых версий. Процедурный интерфейс OpenGL как бы намекает на отсутствие необходимости в глобальном состоянии. Но не тут то было. Для работы с OpenGL необходимо не просто создать контекст, но еще и помнить поток, в котором этот контекст связан с поверхностью вывода. В многопоточной среде контекстов может быть несколько для параллельной загрузки ресурсов. В этом случае помнить надо уже два потока и два контекста (минимум). Само собой, в синглтоне это глобальное состояние смотрится удобнее.
- Sockets. Не важно какие. Когда твое приложение представляет собой MMO проект и у тебя гора подсистем, постоянно и обособленно общающихся с сервером, сетевое подключение разумно оформить в виде синглтона.
- Assets/Resources - они бывают разные, кешируемые и нет, доступные из сети, с жесткого диска, из подсистемы пререндеринга. Опять же, я несколько раз видел боль и страдания от неоднородного контроля ресурсов без соответствующей подсистемы. А сама подсистема управления ресурсами всегда централизована и лучше всего реализуется именно на синглтоне.

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

Answer 3

[Roman Sokolov]

Проще, думаю, объяснить на примере с базой данных.
Допустим у тебя есть программа с несколькими формами, каждая из которых использует какие-либо данные. Если на каждой форме создавать свой объект БД и писать/читать через него данные, то в один момент времени данные между формами могут отличаться и противоречить друг другу.
Для решения этой проблемы создаёшь экземпляр базы данных в единственном состоянии (singletone) и используешь ссылку на него в каждой форме. При этом на каждой форме будут использоваться одинаковые данные.

Answer 4

[protven]

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

Answer 5

[Илья Караваев]

Это же элементарно. Изначально, как замена глобальным переменным. Он один и следовательно все обращения к нему несут изменения во всём проекте. В одном месте вы создали подключение к базе и дальше можете уже использовать его в любой части программы, не пересоздавая подключение и не передавая каждый раз его как аргумент функции.

На самом деле достаточно прочитать любое его описание и становится понятнее.

Comments

[Dauren S]

А почему я не могу использовать статический класс? Или обычный класс? Зачем именно делать синглетон?

[Dauren S]

Зачем мне нужен только единственный экземпляр?

[Илья Караваев]

Dauren: зачем Вам сотня подключений к БД? Зачем Вам сотню раз загружать одни и те же настройки из файла? Зачем? Зачем... Вопрос к архитектуре приложения. Вообще считается плохим тоном использовать множество статических объектом или синглтонов. Поэтому существуют другие полезные шаблоны, например реестры. Ваши вопросы зачем решаются на этапе проектирования системы или в процессе написания кода, если не хватает опыта в дизайне архитектуры приложения. Причина выбора сингтона продиктовано исключительно Вашим выбором. В каждом подходе есть плюсы и минусы. Читайте книги по шаблоном, а не в интернете статьи, в книгах больше информации и описаны причины использования, плюсы и минусы.

[Adamos]

Илья Караваев: я бы все-таки советовал не столько читать (неважно что), сколько применять. Без опыта пристраивания в собственную продуманную архитектуру паттерны так и останутся странной теорией. А вот когда код заиграет и станет очевидным и гибким именно потому, что ты всю его сложность аккуратно разложил по паттернам...

[Илья Караваев]

Adamos: понятое дело, что нужно писать. Я ж так и сказал, решаются в процессе проектирования или написании кода, если не хватает опыта. Применять без прочитанного - заново изобретать велосипед, который банда четырех описала во всех подробностях. А если читать плохое, то и появляются вопросы "зачем".

[Adamos]

Илья Караваев: между прочим, особенно хорошо паттерны ложатся именно поверх изобретенных самостоятельно велосипедов ;)

[Илья Караваев]

Adamos: если таковые имеются... ;) Любая практика хороша и без нее не научиться применять прочитанное.

Answer 6

[trubel]

Посмотрите вебинар по паттернам на Хеклете, где-то с 1:20 начинается обсуждение синглатона, к концу видео подводятся итоги.
Если кратко, синглатон — замена глобальной переменной, чтобы таскать с собой контекст приложения, его использование несет определенные ограничения. Лучше для контекста приложения использовать dependency container.
Вообще рекомендую посмотреть видео целиком, четко расставляет по полочкам про паттерны.

Answer 7

[kahi4]

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

Но придуман он все таки с благой целью: инкапсулировать в себе точки доступа к внешним ресурсам -- как правило, вам нужно одно соединение с базой данных, одна точка с настройками и прочим. И вот, чтобы не создавать каждый раз новый экземпляр, чтобы не выделять ресурсы, чтобы иметь возможность реализовать ленивую (lazy) загрузку и был разработан паттерн, который позволяет обратиться к ресурсу из любой точке приложения и не пробрасывать экземпляры классов/параметры соединения/прочее в каждую функцию, что часто неудобно.

Answer 8

[WAERZ]

Есть
private static $instance = null
И есть

public static function getInstance(){
if (self::instance === null){
 self::instance = new self();
} 
return self::instance;
}

То есть мы помещаем в переменную instance объект класса и потом через getInstance получаем этот объект, а не создаем каждый раз. Это удобно, но нужно использовать только там где стоит. Например для подключения к базе данных.

Answer 9

[cap_nemo]

Иногда возникает необходимость в чем-то единственном...

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

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

Общий смысл - нужно, что-то уникальное, используй его.
Некоторые ребята крутят миниюлу из металла в таких случаях :-)