Singleton - избегайте его
HTML-код
- Опубликовано: 5 сен 2024
- Singleton (класс одиночка) - это один из самых известных паттернов в объектно-ориентированном программировании. К несчастью это скорее всего из-за его очень частоно неверного использования.
Класс одиночка является очень плохим решением для почти любой задачи в разработке реального П.О. и подходит только для быстрого «грязного» решения.
В этом видео уроке я обсуждаю причины для избежания этого паттерна, чем его можно заменить, и как можно начать отказываться от его использования в программном коде, где singleton уже существует.
Может потихоньку наснимаете целый видеокурс по паттернам, по книге "банды четырех"? Лайк кто за!
В принципе я уже собираюсь немного позже сделать видео про Multiton (как только найду как он по-русски называется), ленивую инициализацию, фабрику, и класс-строитель.
Vladimir Mozhenkov
Уж лучше не про паттерны, а про основы объектно-ориентированного проектирования архитектуры, их принципы(не путайте с основами ООП). Паттерны - это сопутствующая тема, изучая которую как алфавит, многие не понимают суть - "зачем они?" и используют их с лютым фанатизмом. В частности было бы интересно послушать такие темы как S.O.L.I.D, DRY, KISS и т.п. В книгах хвататет этого материала, в интернете - все есть, но разорванно, а вот видео, где рассказывается это доступным языком, нет. Думаю, многим было бы интересно. И уверен - написание более-менее сложных программ обязывает изучить этот вопрос!
Отличная идея! Я только за !! Любая помощь автору - пиши=)))
Спасибо, Иисус! Отличный ролик, подписался на канал :D
Хорошая лекция! Но, я бы посоветовал новичкам не принимать все за истину. 1-я проблема - не знаешь, не юзай. Если человек пишет все сам, нет никакой проблемы. 2-я проблема - если человек работает в команде, то это либо очень хреновая команда, либо очень хреновый проектировщик. 3-я проблема - параллельный доступ к одному объекту возможен без проблем если помнить про синхронизацию (а мы обязаны знать где и что синхронизировать, ведь это мы делаем свой синглтон) Чисто мое имхо. Синглтон отлично подходит для всякого рода менеджеров, нельзя его просто так взять и заменить
Видео хорошее, но неправильно названо, надо говорить не Синглтон - плохой паттерн, а как не надо использовать паттерн Синглтон.. Это как говорить микроскоп плохой инструмент- не удобно гвозди забивать, и ломается от этого
Заинтриговало название - стал слушать, ну ерунду говорите. Не надо говорить, что singleton - зло, это не правда. Автор смешал в одну кучу понятие глобальных переменных и singleton'а. Причем проблемы глобальных переменных не описал, сказал как-то вскользь и невнятно. Проблема глобальных переменных в их не детерминизме - могут меняться из разных функций (методов), так что в одном месте ожидается одно, а получаем другое, т.к. было изменено в другом месте. Автор сам же привел пример конфига. Ну подумал бы дальше чуть-чуть - singleton легко сделать readonly (да он в большинстве случаев таким и является (у меня)) и все, проблема глобальных переменных (объектов) уходит. Конфиг же не надо изменять в программе, его надо только читать. Передавать такие обекты как параметры в разные классы - это же ад. И размер объектов увеличивается. И если в дальнейшем потребуется сделать рефакторинг и убрать этот объект, то везде надо будет найти места его передачи. Ну и т.д. Не надо ругать singleton - им надо умело пользоваться.
Согласен. Мне любопытно, ты мобильный разработчик? :)
Почему конфиг не должен меняться? А если я ограничен в памяти, а мне нужно реализовать много вариантов, например, коннектов. Я хочу использовать конфиги для bold, http, https, ftm, ssh, telnet и т.д. но мне они не нужны одновременно и даже больше, одновременно мне они вредны. Зачем мне синглтон? Особенно ридонли синглтон? А если я использую динамическое подключение каких-нибудь компонентов программы. Зачем мне ридонли синглтон в таком случае? А если он не ридонли, то доступен где угодно и его смысл теряется, поскольку есть статичный класс. Опять же, единственное применение синглтона это ридонли конфиг. Больше я не могу придумать ему применений.
Про передачу объекта из точки входа по цепочке: если не использовать патитерн IoC то в большом проекте замучаетесь его передавать.
Интересные мнения, но ну хотелось бы чтобы вы рассказали что использовать вместо данного патерна.
Синглтон хорош, когда нужно сделать программе логгер, с выводом сообщений в файл или куда-то еще.
Все модули и классы будут слать ему свои ошибки.
И лучше сделать этот экземпляр глобальным (доступным из любого места).
В противном случае я должен передавать ссылку или указатель на него через всю иерархию объектов.
Типа: А вот для логгирования ошибок и исключений используй этот объект. Посылай ему сообщения.
Что, согласись, не удобно. Тянуть в конструктор наследника параметр ссылку на объект, который отвечает за сохранение логов.
Проще сделать синглтон, где будет один дескриптор файла и очередь с мьютексом. И все.
Можно писать в тот файл из многих потоков.
Синглтон как раз и имеет смысл, когда его можно передать по ссылке. Если по ссылке не передавать можно обойтись чистой статикой. Естественно, синглтон при этом должен быть не вещью в себе, а реализовывать какой-то интерфейс. Тот же логгер - хороший пример. Код должен работать с абстрактням интерфейсом ILogger, при этом на выбор предлагается (через конфигурацию, к примеру) несколько классов-логгеров: файловый, БД, syslog и т.п. При этом каждый класс реализован как синглтон, т.к. реально не очень хорошо к БД несколько коннектов создавать, к примеру.
Если у программиста руки кривые, то причем здесь одиночка?
Спасибо за интересные видео!
Но я тоже считаю, что нельзя категорично заявлять, что синглтон применять нельзя совсем. Как раз для хранения конфигурации, например, которая считывается однократно и в различных местах программы требуется получить её только на чтение - самое то. Да, когда объект позволяет себя менять, то могут появляться проблемы.
Второй способ - Multiton - похож на паттерн Service Locator. Имеет больше возможностей, но проблемы у него теже.
Реальной заменой синглтону может стать использование контейнеров и dependency injection.
Но к сожалению я сам столкнулся с ситуацией, когда в проекте физически нельзя это использовать (запрещено писать свои конструкторы, через которые можно было бы внедрять зависимости). Поэтому синглтон и сервис-локатор - вполне себе пригодные паттерны. Главное понимать как с ними работать.
Кстати, Володя, вот вам и 2 темы для новых видео: Service Locator и Dependency Injection. :)
А что насчёт синглтона для подключения к БД?
В Web-е синглетон на так уж и плох, в частности, практически везде используется он для создания соединения с базой. Основной минус это сложность покрывать тестами.
Статическая - означает что она принадлежит классу, а не объекту класса
О спасибо! Public static - это прямо про меня совсем недавно :) сейчас вроде как уже пробую ООП, отхожу от этого.
Слышал про синглтон, что его не любят, но только здесь впервые получил подробное объяснение, почему именно его лучше не использовать.
Тут объяснение в видео не очень. В некоторых комментариях тема лучше описана. Синглтон не стоит использовать для сокрытия глобальных переменных, но если вам нужен класс свойства которого финальны и не инициализируются через параметры конструктора, то вполне себе.
Тот кто пишет что Singleton использовать нельзя - как минимум "гуманитарий" .
Если не сказать больше и жестче.
ггг... В таком случае, тот кто пишет основываясь на синглтонах не видя других более практичных опций - говнокодер? :)
Здраствуйте. Один из популярных фреймфорков Yii использует этот синглтон. Вроде ниче, все работает даже на ура.
Хорошие у Вас видео. Спасибо за труды =)
Multiton это , я так понял, dependency injection ?
Авторы веб-фрейморков с вами не согласны :) Причем на чем бы они их не писали (тут я за все не отвечаю, конечно :) ). И всякого рода "фасады" - тоже слишком близко к идее синглтона,особенно в части "засунуть общий функционал под один капот".
Полагаю, в таком контексте, который предполагает выполнение кода "в один проход", как, например, в обработчике http-запроса, особых сложностей с возможным пересечением вызовов синглтона нет по определению. Плюс, не забываем, что "просто так" статическое поле в джаве между потоками не шарится, если я ничего не путаю :)
Конечно, можно передавать по цепочке объекты общего использования, типа конфига, или авторизации. Но все это зачастую приводит к куда более худшим последствиям, в виде сильной связности и многочисленных, спорной полезности, параметров в сигнатурах методов. И решается подобная "лапша" разного рода статическими методами, синглтонами, рефлекшенами, разного рода реализациями АОП и прочей магией. Ибо, меньше кода - всегда лучше, как минимум, для програмера :)
Это я как бы не полемизирую, а вношу дополнение в картину мироздания :)
Сергей Лесс Если под этим вы хотите сказать что нет одного правила для всех разработок, то конечно-же вы правы. Я знаю даже пару примеров, где GOTO можно использовать для достижения нужных результатов и лучшей читабильности кода. Но дело в том, что *как правило* одиночку стоит избегать.
Вот и я о том же... "передавать объекты конфига по цепочке"... хорошо сказано!
На джаве может быть синглтон, который не сработает, например, если вы неправильно создаете томкат сервлет и на одних и тех же данных работают (по вашей ошибке) два сервлета с разными класслоадерами. Тогда и класса будет два внутри одной машины, как ни защищайся.
Ну, например, я конфиги обычно парсю в синглтон. Предложите более подходящий вариант.
ИМХО, у автора - сугубо предвзятое отношение к синглтону. Сама реализация синглтона гарантирует наличие единственного экземпляра, для сохранения глобального состояния, а гарантировать это какими-то сторонними костылями, чтобы передавать ссылку другим экземплярам - изврат полнейший, ИМХО, и не такой надежный, с учетом того, что код постоянно кто-то педалит, и привносит новые баги.
Кроме того, сегодня нужно, чтобы класс имел доступ к конфигурации, завтра - не нужно, послезавтра - снова нужно и т.д. - будут меняться сигнатуры, или наследование класса? Данунафиг, особенно если это - публичный класс, и публичная сборка.
Вообще, по определению, ООП моделирует поведение реальных объектов. Пример с синглтоном, хранящий конфигурацию - очень хороший. Так вот в реальном мире , если мне нужно посмотреть в ресторане меню - я ведь не буду просить официанта подать мне меню, которое уже на столе передо мной лежит. И тем более, не буду просить его мне его в слух прочитать, т.к. у меня есть свои глаза :)
Вы бы лучше рассказали, как его правильно использовать, для чего существуют в нем дополнительные блокировки (например, double-lock singleton)
А наследоваться от синглтона, с учетом его определения - ИМХО, это изврат, в первый раз слышу, чтобы кому-то это на ум пришло. Застрелиться - и пальцем можно :)
И пример на последней секунде, где пустой класс с публичными статическими членами - трэш и угар при использовании в многопоточности, стоило бы об этом сказать.
11
Valentin Rusk я тебе как principal architect, с более чем 16 летним коммерческим опытом могу сказать, что этот твой говеный декоратор нужно засунуть в одно место: во-первых, это как камень, об который все спотыкаются. во-вторых, не бывает идеальной архитектуры. есть лишь ключевые параметры, которые архитектор закладывает. обычно это скорость разработки, и легкое сопровождение, что само по себе - антагонизм. в третьих, термин сабклассинг, сабкласс и т.д. - это вообще какая-то хрень безграмотная. вот зэ фак из сабкласс? :)
костыли городить, вместо того, чтобы системно проблему решить - это не есть хорошо.
А существующий код - бугага, еще и как переписывается! Изменит заказчик бизнес-процессы - и будешь сношаться с кодом, и все заново перетестивать. Как ты думаешь, автотесты придумали от хорошей жизни, что ли?
22
Согласен полностью, если его правильно использовать, он очень выручает.
14:50 *ля, прям про меня xDDD
Singleton всего лишь заменяет статический класс (добавляя немного плюсов в виде возможности его расширения через наследование), и все перечисленные для него минусы относятся и к статическим классам.
А статические классы используются, например, в c# для математических функций и т.п.
я конечно извеняюсь, но сингтон БАЙ ДЕФИНИШН не должен расширятся, по этому помимо конструктора, клон и пр. ) а если конструктор закрыт (приватный) - как ты можешь его наследовать? ;)
Valentin Rusk ничто не мешает сделать конструктор protected - открытый только для наследников.
Думаю автор не совсем прав, синглтон не антипаттерн, элементарно через него очень удобно организовать кэширование чего либо.
Антипаттерн и удобство не исключают друг друга. Можно писать удобно, в угоду отладки, например. Возможно, неиспользование синглтона - это совет новичкам, а когда набъешь руку, то знаешь, как надо. Таких советов полно - нельзя делать то, нельзя делать другое. Можно, но только, когда ты эксперт в этом, и ты видишь все варинаты плюсов и минусовподхода и идешь на компромисс.
..."статическая" - означает, что будет только одна переменная...
И далее дофига подобного странного.
Блин, дослушал до половины, больше не могу. Это не лекция, это проповедь.
Синглетон позволяет задать порядок инициализации глобальных объектов. Например у нас есть два глобальных объекта в разных единицах трансляции. По стандарту порядок вызова их конструкторов не определен. А если мы представим эти объекты синглетонами, при том, что один будет запрашивать второй, то получим однозначно заданный порядок инициализации.
для этого есть другие паттерны, которые снимут твою головную больше) возьми к примеру Template. ;) и наслаждайся=)
+Valentin Rusk подробнее расскажите про темплэйт и что вы имеете в виду.
есть паттерн такой, который позволяет задать очередность исполнений заранее на уровне абстракции.
@@xbugster Паттерн Template совсем про другое. Он нужен чтобы выделять общие методы в абстрактный класс. Давай, покажи мне как Template использовать для кеширования глобальных данных.
Синглтон довольно часто встречается в Java SDK, например, java.lang.Runtime, java.awt.Toolkit, java.awt.Desktop... Возникает вопрос, а не являются ли инженеры Sun идиотами? Думаю, что нет. Эта оболочка необходима для защиты данных и логики их инициализации, так, что использование "голых" статических переменных не равносильно использованию Синглтона. Его использование может сбивать с толку, но так же может и помогать: например я вижу незнакомый проект, а в нём класс с private-конструктором и характерным статическим объектом. Тут я уже понимаю, что его содержимое уникально в некотором роде, как например, класс доступа к модулю GPS в смартфоне. Ведь у нас есть только один физический GPS модуль. Аминь!
Я не думаю, что разработчики Sun идиоты. Но я думаю, что они ошибочно использовали одиночку. Тут надо от части смотреть, когда разрабатывались библиотеки Java. Сегодня скорее всего они такого-бы не сделали.Хотя в Scala одиночки используются повсюду, но там они переделаны в нечто весьма иное, и мне кажется используются правильно, как точки входа или временные объекты.
Vladimir Mozhenkov В Scala ведь одиночки - это сущность на уровне языка, как и в Ruby?
Сергей Лесс Не знаю Ruby вообще, в Scala вы просто сразу пишите object Name и это объект одиночка. Так что да, на уровне языка. )))
Точно. С Руби - это я видимо напутал что-то. Мне он показался во многом похожим на Scala, когда читал мануалы по обоим языкам :)
Сергей, руби вообще гэ без особой поддержки ООП... пишу уже на нем довольно долго... велосипеды, велосипеды ради норм ооп... ))) реализуем собственные абстракции в силу их отсутсвия, депенси инжекшены и пр ))) а что делать.... жизнь с руби не легка :-D
Здравствуйте уважаемый автор, я имею небольшой опыт ООП проектирования. И ввиду малого опыта хотел прояснить кое какие моменты.
Во первых для меня одиночка более широкое понятие, в отличие от Вашего. Я его понимаю как инструмент для получения ограниченного доступа к каким либо ресурсам приложения - необязательно одного, например 10 подключений к базе данных.
Во вторых все названные проблемы собственно как раз и являются целью паттерна - ограничение доступа к чему либо.
В примере с подпрограммами, мне кажется, если возникла такая ситуация изначально была неверная архитектура приложения.
И еще вопрос. Необходимо организовать более гибкую блокировку данных на уровне приложения в многопоточном прложении, которую не может дать база данных. Каким образом это сделать не использую Одиночку?
Иван Владимирович Я с вами почти полностью согласен, у каждой вещи есть свои возможности. И я сам использую класс одиночку, когда это необходимо. Тут проблема вот в чём. Очень часто у вас нет необходимости этого делать. Например вы сказали что у вас многопоточное приложение, и вы хотите получить доступ к базе данных определённым образом. Я не знаю ни одного языка программирования, который не позволяет передать какой-то объект при создании нового потока. То есть:
// при начальной загрузке вашего приложения
DatabaseConnector conn = new DatabaseConnector(/* ... */);
// ...
// при создании новых потоков
Runnable newR = new MyClass(conn);
Теперь ваш поток будет знать как подключиться к базе данных, и вы убрали у себя все возможные проблемы. То есть да, у Singleton-а есть свои использования, но ваш пример как раз таковым не является. Тестирование вашей программы стандартными пакетами будет на много сложнее, вы совершенно не можете делать тестирование закрытой (чёрной) коробки (black box testing). Так как внутри вашего класса он умудряется получить доступ к объекту одиночке, а узнать это тестер мог только просмотрев код.
Я бы посоветовал товарищу выше, посмотреть твою лекцию по энкапсуляции, а так же по композиции! =))) так же почитать и вникнуть в SOLID принципы, чтобы понять почему синглтон это - плохо! Володя, давай паттерны серьезнее! ) в стиле арх. паттернов publisher subscriber, finite state machine, data mapper, mvc и пр.=)))
Володя, спасибо за видео! Вы бы не могли записать или направить меня на ваше видео на тему "Чистая функция" в контексте данного видео. Дело в том, что не совсем понятно, если функция изменяет результат getInst, то это функция с побочным действием как и вывод в sout?
Singleton хороший, singleton молодец, не обижайте его, разве вы не догадались - singleton потому и называется single, потому что он предназначен для single програмирвоня)
Если у синглтона хорошо проработан интерфейс, то программа разве может начать непредсказуемое поведение? Тогда ведь неважно кто, сколько , как и что вызывает.
Вполне приемлемо использовать синглтон соблюдая принцип SRP
Спасибо за видео, но я не разделяю мнение автора и все еще считаю что это все надуманно и неубедительно.
Возможно, у вас рука набита. Мне как новичку оч убедительно прозвучало. Согласитесь, мне запрещено использовать такой подход, т.к. я могу горя хапнуть, в то время, как вы спокойно учитываете все риски связанные с инкапсляцией, наследованием и т.д. А вот, когда я набью руку, то и мне можно будет пользоваться.
Иисус! А видео хорошее :)
У вас нет очной школы для обучения? Было бы круто в Москве походить на уроки. Кому-то возможно потребуется повышение квалификации, а кому-то полная переквалификация. Было бы здорово!
а вот про public static интересно.
это же что-то вроде класса утилит
на мой взгляд это будет получше, чем синглтон.
если например он не хранит данные.
просто часто бывают ситуации, когда работаешь с чужим кодом, который не можешь менять.
и в то же время не можешь наследоваться.
тогда утилитки выручают
Володя, ты отличный проф !!! Давай лекции на английском тоже!!! много народу интересуются, а русского не знают!!
Упускаешь огромную аудиторию не пуганых ... :-D
Singleton - под запретом??? Если в расматривать его в вакууме - то да, но на практике, в реальных приложениях программа зачастую являеться отражением существующей дейстьвительности, а она в основном иерархична, т.е. рулится неким арбитром, который должен быть всегда один. Афтар если не одиночка, - то ответь как ты гарантируешь единственный инстанс арбитра?.
У синглетона были проблемы в многопоточных приложениях, но атомарные переменные в купе с барьерами памяти ее успешно решили
Вы программист?
Да ☺
почти бред
Это очень сложно без реальной программы как пример.
Я не хочу оскорбить или обидеть автора и я не сомневаюсь в его навыках программирования , но мне кажется проблема не в самом шаблоне, а в его применение .
Опять же я могу ошибаться в свете своего скудного опыта.
Till Kruspe Я совершенно не оскорбился. Во-превых, реально есть многие вещи в программировании, о которых можно поспорить. Возьмите машину Даффа, многие считают её антипаттерном. И естественно если у вас есть причины не соглашаться со мной, то не соглашайтесь. Но в высказывании несогласия будьте добры высказать причину мнения. Мои навыки программирования тут совершенно не при чём.
Я выскажу причину несогласия с Вами. Синглтон может использоваться из разных мест в коде, не передавая в через вызовы туда ссылки на объект синглтона, вызывая getInst() там, и только там где нужно. Если программа многопоточная - то так или иначе необходимо синхронизировать состояния во избежание гонки, не важно, обращаемся ли мы к объекту как к синглтону или нет.
Лишь из-за его неправильного применения могут возникнуть проблемы и неудобства. Я видел джунов, начитавшихся литературы про паттерны и пытающихся их применять там, где им не место. Но ведь это же не делает плохими сами паттерны!
Ой-ой - "быстро грязно накидать говнокод синглтонами". Слишком спорные вещи во второй части говорите.
А так все правильно, опять же простая истина "нехуй использовать паттерны бездумно", сигнлтон - точка доступа к какому-либо фукнционалу.
Не стоит наследоваться от синглтона да и статические методы всегда должны быть потокобезопасны, это и так ясно.
Это виски
Мне было не очень интересно смотреть это видео, до того момента пока не зашла речь о идентификаторе или облаке(отличное название), так как я один из тысяч программистов который стал невольно его (со)автором...
Я видел массу людей которые из ООП понимают только наследование и смеются со слов агрегация или ассоциация, таким людям нельзя использовать такие паттерны как одиночка, потому что они будут пытаться унаследоваться от него - так как они не понимают, что существуют еще и др. варианты отношений классов.
Этот паттерн не для того что б от него наследовались, а для того что б его использовали в других класса, что б не писать 10 раз один и тот же код, и что б работало/загружалось все быстро, и ресурсов кушало меньше - соответственно.
theDenQ Согласен что *как правило* одиночка не может быть родительским классом. Но бывают случаи, где такое желательно. А на счёт композиции и агрегации, проблема возможно в том, что в отличие от наследования сложно ткнуть пальцем в кусок кода и сказать "вот агрегация" (потому что нужно смотреть на весь цикл жизни объекта). Плюс не стоит забывать, что классы эволюционировали от структур, а там композиция - это просто использование одной структуры внутри другой, и никто не задумывался, что этому надо дать имя.
Держите сумашедшего.
1. ООП принцип инкапсуляции. Тебе не надо знать реализацию. Для тебя это черный ящик.
2. Программа которая превращена в подпрограмму сама по себе является синглтоном.
3. Ошибочное понимание. Синглтон это не статический класс, экземпляр скрытого объекта (instance) создаётся обычным образом, он не статический. Отсюда вывод, в каждой программе будет свой синглтон.
4. Привет тебе от DI/IoC, с loose couple. Продолжай жестко связывать объекты.
Автор действительно понимает ООП ?
Угу. ООП, принцип инкапсуляции. В видео приведен аргумент, когда нарушен этот принцип. Для тебя черный ящик, который ломает поведение программы. А вы точно понимаете ООП?
Скажите, а почему инстанс у вас не статический? Есть ли в открытом доступе ваш когд, я бы посмотрел реализацию? Просто, оч странное заявление. Не боитесь, перезатереть объект? Одним из признаков синглтона - статически создающийся метод, который возвращает один и тот же объект.
что то совсем масло масляное
Ага мне нужно в программе иметь одно подключение к базе чтоб не плодить утечки памяти. Давайте нахер выкинем патерн который решает эту проблему
А если я не хочу чтоб моё приложение создавало два окна, то я просто возьму и сделаю class Window как singleton.Его нужно избегать если не понимаешь зачем он нужен.И всё таки многие используют singleton.Например движок Gameplay , в нём разрешено только один раз унаследоваться от класса Game . Неужели скажите что они плохие программисты? Почти 3 тыщи звёзд и тысячи форков у этого движка
github.com/gameplay3d/GamePlay/blob/4de92c4c6f8047db5dcb7f0dee8541c7e7ea5a80/gameplay/src/Game.h#L78
О господи, будь проще.
Huh?
жжешь
Автор ахинею несет.