Синоним слова синглтон будет "глобальная переменная". Уже лет 50 все книги-буквари по программированию пишут одно и то же : "Избегайте глобальных переменных". Люди действительно стали избегать — практически везде, где раньше были глобальные переменные, выросли синглтоны. Что интересно — все проблемы остались. Фактически, такой синглтон просто замыкает самые разные контексты и является ни чем иным, как способом управления депенденсами, негибким, проблемным и очень непредсказуемым.
Есть простой подход, который позволит понять, о чем идет речь — заменяем слово "синглтон" на "глобальная переменная" и смотрим, что же изменилось. Обычно речь про единственный экземпляр какого то типа. Но, извините, синглтон и единственный экземпляр это немного разные понятия. Синглтон требует, что бы была глобальная точка входа. Более того, должна решаться какая то проблема, например — долгая инициализация, засорение глобального неймспейса и тд.
Вобщем, получается так, что для паттерна Синглтон есть почти одно применение — глобальный объект навроде App.
Множество других применений как правило сильно искусственные. Например класс DataBase. Ну есть у приложения ровно одна база данных, и что с того ? что мешает создавать экземпляры по требованию ? Если технических проблем нет, то синглтонить класс для работы с базой мягко говоря очень странный подход.
Вообще говоря, мой подход с паттернам примерно такой — сначала решить задачу, а потом переводить решение в код. Если на втором этапе возникают ассоциации с паттернами, то, как вариант, можно посмотреть варианты решения просто для уточнения деталей. Писать или не писать конкретный паттерн явно в коде это вообще дело десятое. Паттерн вообще должен решать одну или несколько реальных проблем и, при этом, должен хорошо вписываться в глобальный дизайн решения. Если этого нет, то паттерн есть просто баззворд.
За употребление паттернов на первом этапе, то есть на стадии поиска и принятия решения, считаю, надо бить по рукам, головам, почкам и даже ниже пояса любыми способами — явными, неявными, прямыми, косвенными, симметричными, ассиметричными и тд и тд и тд.
Если ограничить применение Синглтона именно глобальным объектом App, то, внезапно, из этого можно извлечь целый ряд профитов. Например можно ввести просто адскую диагностику средствами REPL. А можно менять стратегии персистанса глобального состояния. Забрать у классов эту обязанность и переложить её на фремворк приложения — пусть он решает, где и как будет сохраняться состояние приложения и будет ли вообще сохраняться. Что же должно храниться в этом объекте ? Хранить нужно собтсвенно состояние, время жизни которого
1. равно времени жизни экземпляра приложения
2. больше времени жизни экземпляра приложения
Собственно всё.
23.06.14 13:05: Перенесено модератором из 'Блоги' — AndrewVK
I>Синоним слова синглтон будет "глобальная переменная". Уже лет 50 все книги-буквари по программированию пишут одно и то же : "Избегайте глобальных переменных". Люди действительно стали избегать — практически везде, где раньше были глобальные переменные, выросли синглтоны. Что интересно — все проблемы остались. Фактически, такой синглтон просто замыкает самые разные контексты и является ни чем иным, как способом управления депенденсами, негибким, проблемным и очень непредсказуемым.
Т.е. ты за DI и прочие IoC, я правильно понял?
I>Есть простой подход, который позволит понять, о чем идет речь — заменяем слово "синглтон" на "глобальная переменная" и смотрим, что же изменилось. Обычно речь про единственный экземпляр какого то типа. Но, извините, синглтон и единственный экземпляр это немного разные понятия. Синглтон требует, что бы была глобальная точка входа. Более того, должна решаться какая то проблема, например — долгая инициализация, засорение глобального неймспейса и тд.
При чём тут неймспесы?
I>Вобщем, получается так, что для паттерна Синглтон есть почти одно применение — глобальный объект навроде App.
У кого получается? У тебя?
Это прекрасно.
I>Множество других применений как правило сильно искусственные. Например класс DataBase. Ну есть у приложения ровно одна база данных, и что с того ? что мешает создавать экземпляры по требованию ? Если технических проблем нет, то синглтонить класс для работы с базой мягко говоря очень странный подход.
А что, синглтон по требованию созать нельзя?
I>Вообще говоря, мой подход с паттернам примерно такой — сначала решить задачу, а потом переводить решение в код. Если на втором этапе возникают ассоциации с паттернами, то, как вариант, можно посмотреть варианты решения просто для уточнения деталей. Писать или не писать конкретный паттерн явно в коде это вообще дело десятое. I>За употребление паттернов на первом этапе, то есть на стадии поиска и принятия решения, считаю, надо бить по рукам, головам, почкам и даже ниже пояса любыми способами — явными, неявными, прямыми, косвенными, симметричными, ассиметричными и тд и тд и тд.
Да-да, и тут ты на Белом Коне с шакой наголо.
I>Если ограничить применение Синглтона именно глобальным объектом App, то, внезапно, из этого можно извлечь целый ряд профитов. Например можно ввести просто адскую диагностику средствами REPL. А можно менять стратегии персистанса глобального состояния. Забрать у классов эту обязанность и переложить её на фремворк приложения — пусть он решает, где и как будет сохраняться состояние приложения и будет ли вообще сохраняться. Что же должно храниться в этом объекте ? Хранить нужно собтсвенно состояние, время жизни которого I>1. равно времени жизни экземпляра приложения I>2. больше времени жизни экземпляра приложения
Какой-то поток сознания...начали с паттерна, перешли к какой-то прикладной проблематике.
I>Собственно всё.
Ниачём.
Ждём срыва покровов с goto.
Здравствуйте, dr. Acula, Вы писали:
I>>Синоним слова синглтон будет "глобальная переменная". Уже лет 50 все книги-буквари по программированию пишут одно и то же : "Избегайте глобальных переменных". Люди действительно стали избегать — практически везде, где раньше были глобальные переменные, выросли синглтоны. Что интересно — все проблемы остались. Фактически, такой синглтон просто замыкает самые разные контексты и является ни чем иным, как способом управления депенденсами, негибким, проблемным и очень непредсказуемым. DA>Т.е. ты за DI и прочие IoC, я правильно понял?
Я не знаю, что значит "за DI и IoC". Самый интересный вариант IoC на мой взгляд это использование лямбда-выражений в таких вещах, как Linq в .Net или Stream в Джава.
Вероятно, ты имел ввиду управление депенденсами. Да, я за то, что бы управлять депенденсами, при чем явно, что бы все вещи типа состояние, время жизни, аггрегирование, делегирование, композиция и тд были видны с первого взгляда, а не размазывались тонким слоем по сотне классов.
I>>Есть простой подход, который позволит понять, о чем идет речь — заменяем слово "синглтон" на "глобальная переменная" и смотрим, что же изменилось. Обычно речь про единственный экземпляр какого то типа. Но, извините, синглтон и единственный экземпляр это немного разные понятия. Синглтон требует, что бы была глобальная точка входа. Более того, должна решаться какая то проблема, например — долгая инициализация, засорение глобального неймспейса и тд. DA>При чём тут неймспесы?
При том, что глобальные переменные независимо от происхождения засоряют этот самый неймспейс. И часто возникает путаница со всеми сопутствующими проблемами.
I>>Множество других применений как правило сильно искусственные. Например класс DataBase. Ну есть у приложения ровно одна база данных, и что с того ? что мешает создавать экземпляры по требованию ? Если технических проблем нет, то синглтонить класс для работы с базой мягко говоря очень странный подход. DA>А что, синглтон по требованию созать нельзя?
Можно, только зачем ? Ответь на вопрос — какую проблему ты решаешь, делая класс базы данных синглтоном ?
I>>1. равно времени жизни экземпляра приложения I>>2. больше времени жизни экземпляра приложения DA>Какой-то поток сознания...начали с паттерна, перешли к какой-то прикладной проблематике.
I>>>Синоним слова синглтон будет "глобальная переменная". Уже лет 50 все книги-буквари по программированию пишут одно и то же : "Избегайте глобальных переменных". Люди действительно стали избегать — практически везде, где раньше были глобальные переменные, выросли синглтоны. Что интересно — все проблемы остались. Фактически, такой синглтон просто замыкает самые разные контексты и является ни чем иным, как способом управления депенденсами, негибким, проблемным и очень непредсказуемым. DA>>Т.е. ты за DI и прочие IoC, я правильно понял?
I>Я не знаю, что значит "за DI и IoC".
Okay... I>Самый интересный вариант IoC на мой взгляд это использование лямбда-выражений в таких вещах, как Linq в .Net или Stream в Джава.
Офигеть, чо.
I>Вероятно, ты имел ввиду управление депенденсами. Да, я за то, что бы управлять депенденсами, при чем явно, что бы все вещи типа состояние, время жизни, аггрегирование, делегирование, композиция и тд были видны с первого взгляда, а не размазывались тонким слоем по сотне классов.
Какие сотни классов?
Тебе не видно состояние в синглтоне?
I>>>Есть простой подход, который позволит понять, о чем идет речь — заменяем слово "синглтон" на "глобальная переменная" и смотрим, что же изменилось. Обычно речь про единственный экземпляр какого то типа. Но, извините, синглтон и единственный экземпляр это немного разные понятия. Синглтон требует, что бы была глобальная точка входа. Более того, должна решаться какая то проблема, например — долгая инициализация, засорение глобального неймспейса и тд. DA>>При чём тут неймспесы? I>При том, что глобальные переменные независимо от происхождения засоряют этот самый неймспейс. И часто возникает путаница со всеми сопутствующими проблемами.
Еще раз. При чём глобальный неймспейс к синглтону?
I>>>Множество других применений как правило сильно искусственные. Например класс DataBase. Ну есть у приложения ровно одна база данных, и что с того ? что мешает создавать экземпляры по требованию ? Если технических проблем нет, то синглтонить класс для работы с базой мягко говоря очень странный подход. DA>>А что, синглтон по требованию созать нельзя? I>Можно, только зачем ? Ответь на вопрос — какую проблему ты решаешь, делая класс базы данных синглтоном ?
Я не обсуждаю с тобой твои выдуманные примеры БД как синглтона — очевидно, что БД так не делают.
Я у тебя спрашивал именно о выделенном — "что мешает создавать экземпляры по требованию".
Что мешает в случае синглтона?
I>>>1. равно времени жизни экземпляра приложения I>>>2. больше времени жизни экземпляра приложения DA>>Какой-то поток сознания...начали с паттерна, перешли к какой-то прикладной проблематике. I>Именно так и было задумано.
Типичный вариант твоей "дискуссии".
Здравствуйте, dr. Acula, Вы писали:
DA>Какие сотни классов?
Такие. В больших приложениях много классов.
DA>Тебе не видно состояние в синглтоне?
Нет, не видно. Синглтон всегда имеет состояние и это состояние пинают все, кому не лень. Отсюда ясно, что в каждом конкретном месте ты видишь только малую часть, а остальная нигде не видна.
Если создавать инстанс
I>>При том, что глобальные переменные независимо от происхождения засоряют этот самый неймспейс. И часто возникает путаница со всеми сопутствующими проблемами. DA>Еще раз. При чём глобальный неймспейс к синглтону?
А ты понимаешь, что я говорю о том, что синглтоны пришли на замену глобальным переменным ? Ты понимаешь, что глобальные переменные означали кучу глобально видимых функций.
I>>>>Множество других применений как правило сильно искусственные. Например класс DataBase. Ну есть у приложения ровно одна база данных, и что с того ? что мешает создавать экземпляры по требованию ? Если технических проблем нет, то синглтонить класс для работы с базой мягко говоря очень странный подход. DA>>>А что, синглтон по требованию созать нельзя? I>>Можно, только зачем ? Ответь на вопрос — какую проблему ты решаешь, делая класс базы данных синглтоном ? DA>Я не обсуждаю с тобой твои выдуманные примеры БД как синглтона — очевидно, что БД так не делают.
Вообще говоря делают постоянно, не пойму зачем.
DA>Я у тебя спрашивал именно о выделенном — "что мешает создавать экземпляры по требованию". DA>Что мешает в случае синглтона?
Не понял, ты хочешь иметь синглтон что бы создавать экземпляры по требованию ? А зачем тогда синглтон, если экземпляры создаются по требованию.
Смотри:
var x = new MegaDatabaseClass();
Не пойму, зачем мне здесь какой то синглтон и какую проблему он решит в данном случае
I>>Именно так и было задумано. DA>Типичный вариант твоей "дискуссии".
Здравствуйте, Ikemefula, Вы писали:
I>Синоним слова синглтон будет "глобальная переменная". Уже лет 50 все книги-буквари по программированию пишут одно и то же : "Избегайте глобальных переменных". Люди действительно стали избегать — практически везде, где раньше были глобальные переменные, выросли синглтоны. Что интересно — все проблемы остались. Фактически, такой синглтон просто замыкает самые разные контексты и является ни чем иным, как способом управления депенденсами, негибким, проблемным и очень непредсказуемым.
Я бы не ориентировался на рекомендации GoF, они здорово устарели. В более-менее современных источниках пишут буквально то же самое, что и ты:
Nonetheless, singletons have problems similar to globals; e.g., creating dependencies in vastly separated parts of the system, so side effects can appear far afield from their causes. Often singletons are abused by inexperienced programmers who think that the use of the pattern will magically solve all the problems associated with GlobalVariables. (See SingletonGlobalProblems for more.)
Кстати, GoF (насколько помню) нигде не утверждали, что синглтон отличается от глобальной переменной. Скорее, синглтон == глобальной переменной + контроль за отсутствием дублирующих глобальных переменных.
Здравствуйте, RSATom, Вы писали:
RSA>Думаю, когда однажды, количество аргументов некоторой функции перевалит за десяток, синглетон перестанет выглядеть такой уж страшной вещью...
Штоа?! Можно пример проблемы, когда этого не избежать? я вот собственно не понимаю как связано ограничение по количеству объектов недетерминированность время жизни объекта с сигнатурой метода. Это из серии "при какой температуре кипит прямой угол?"
Здравствуйте, RSATom, Вы писали:
RSA>Думаю, когда однажды, количество аргументов некоторой функции перевалит за десяток, синглетон перестанет выглядеть такой уж страшной вещью...
Когда количесттво аргументов увеличивается, нужно свернуть аргументы упаковывая в отдельный класс. Отсюда, внезапно, начинает расти новая абстракция, которую можно рафинировать через рефакторинг при необходимости.
I>Синоним слова синглтон будет "глобальная переменная".
Хочу предложить взглянуть на проблему с другой стороны. Рассмотрим случай никак не связанный с синглтонами. У нас есть приложение в котором есть базовый класс по работе с БД. Там уже есть вся инфраструктура по чтению из конфига строки подключения и созданию этого подключения. Тем не менее любой мастер костыля может в наследнике такого класса создать новое подключение и прописать свой метод чтения из конфига. И нет средств языка, которые ему бы помешали это сделать. Получается, средства языка порой очень ограничены в том, чтобы запретить разработчику ошибиться.
Вообще, все прайвты, паблики, зоны видимости и прочее — это же про "защиту от дурака", намек на то, как надо использовать код. Но ищущий костыля всегда найдет способ хакнуть прайвт метод через рефлекшн.
Вернемся к синглтону. На мой взгляд, тот факт что синглтон == глобальная переменная — это просто случайное совпадение в реально существующих языках. Цель паттерна синглтон простая — обеспечить, чтобы всегда был единственный экземпляр класса. То, что при этом этот единственный экземпляр можно вызвать напрямую отовсюду — это печально, но не более печально, чем то, что для обычного класса можно всюду создать новый экземпляр, как в примере выше. Ну а как правильно использовать синглтон — не секрет, надо обозначать его использование, передавая его в конструктор или свойства класса явно.
App — это как правило очень сильная связанность, явная или неявная. Получается любой кто хотел знать только про что-нибудь одно, должен/будет знать о всем мире.
Здравствуйте, RSATom, Вы писали: RSA>Думаю, когда однажды, количество аргументов некоторой функции перевалит за десяток, синглетон перестанет выглядеть такой уж страшной вещью...
единая точка доступа к контроллерам приложения (ее можно назвать App, а я, например, называю Core) это по сути единственный правильный известный мне способ использования синглтона
RSA>>когда однажды, количество аргументов некоторой функции перевалит за десяток, синглетон перестанет выглядеть такой уж страшной вещью... I>Когда количесттво аргументов увеличивается, нужно свернуть аргументы упаковывая в отдельный класс.
Эта мантра не поможет, ибо конструктор(=инициализация) упаковки никуда не денется.
Здравствуйте, Аноним, Вы писали:
RSA>>>когда однажды, количество аргументов некоторой функции перевалит за десяток, синглетон перестанет выглядеть такой уж страшной вещью... I>>Когда количесттво аргументов увеличивается, нужно свернуть аргументы упаковывая в отдельный класс. А>Эта мантра не поможет, ибо конструктор(=инициализация) упаковки никуда не денется.
Это смотря как упаковывать. А после упаковки очень часто нарисовыватся новая абстракция, которую можно полить, окучить и вырастить при желании
Re[5]: О синглтонах
От:
Аноним
Дата:
23.06.14 21:14
Оценка:
I>Это смотря как упаковывать.
А, вы, все еще кипятите? С мантрами всегда так. Главное — чаще повторять. С вами скучно. Гудбай.
Здравствуйте, diez_p, Вы писали:
_>Здравствуйте, RSATom, Вы писали:
RSA>>Думаю, когда однажды, количество аргументов некоторой функции перевалит за десяток, синглетон перестанет выглядеть такой уж страшной вещью...
_>Штоа?! Можно пример проблемы, когда этого не избежать? я вот собственно не понимаю как связано ограничение по количеству объектов недетерминированность время жизни объекта с сигнатурой метода. Это из серии "при какой температуре кипит прямой угол?"
Ок, приведу пример. В программе могут быть как минимум следующие глобальные (по сути) сущности:
1) Gui Application object — т.е. нечто что необходимо для создания окошек/контролов
2) Logger Object — из названия понятно, для ведения логов.
3) Config Object — для доступа к текущей конфигурации приложения.
Если не использовать синглетоны — огромное количество функций/конструкторов должены будет получать некоторые/все из этих сущностей, а так же передавать далее. Кроме того, в экземлярах классов нужные сущности придется хранить, а это увеличиит каждый экземпляр класса на sizeof(void*) * n, где n = 1..3
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, RSATom, Вы писали:
RSA>>Думаю, когда однажды, количество аргументов некоторой функции перевалит за десяток, синглетон перестанет выглядеть такой уж страшной вещью...
I>Когда количесттво аргументов увеличивается, нужно свернуть аргументы упаковывая в отдельный класс. Отсюда, внезапно, начинает расти новая абстракция, которую можно рафинировать через рефакторинг при необходимости.
Можно, но:
а) порой эти аргументы между собой абсолютно не связаны (как например логер и конфиг)
б) разные функции могут требовать разные сочетания параметров — будем плодить структуры на каждое потребовавшееся сочетание? Или создадим суперкласс и свяжем всех со всеми кованными цепями?
Главная идея вашего сообщения которую мне хотелось бы явно выделить — среди программистов тоже бывают дураки, и термин "защита от дурака", должен применяться не только относительно пользовательских интерфейсов, но и относительно программных. А с учетом возрастающего в геометрической прогрессии количества фреймворков, и среднестатистической уровня знания программистами этих фреймворков — ценность "защиты от дурака" возрастает так же в геометрической прогрессии. Просто потому что разобраться в тонкостях каждого из фреймовроков не хватает времени. А если учесть что фаворит каждые полгода новый...
Здравствуйте, RSATom, Вы писали: RSA>Ок, приведу пример. В программе могут быть как минимум следующие глобальные (по сути) сущности: RSA>1) Gui Application object — т.е. нечто что необходимо для создания окошек/контролов
в нормально спроектированном приложении окошки-контролы создаются не из логики, а только из view, а view по сути и является таким обьектом. но так как мы должны иметь свое view для модели, то нелогично не самом деле иметь view-синглон
RSA>2) Logger Object — из названия понятно, для ведения логов.
да, обычно это синглтон. точнее, это вообще обычно макрос в С++, в явном виде никто с синглтоном не работает
RSA>3) Config Object — для доступа к текущей конфигурации приложения.
"конфиг" это криво реализованная сериализация. не надо на самом деле никаких конфигов городить в нормально спроектированном приложении или по крайней мере это не должно быть синглтоном
RSA>Если не использовать синглетоны — огромное количество функций/конструкторов должены будет получать некоторые/все из этих сущностей, а так же передавать далее. Кроме того, в экземлярах классов нужные сущности придется хранить, а это увеличиит каждый экземпляр класса на sizeof(void*) * n, где n = 1..3
да, это одна из первых проблем новичков. поэтому, как классическое решение, возникают контроллеры сущностей и единая точка доступа к контроллерам приложения, которая да, является синглтоном. но это один синглтон на приложение, а не куча на каждую сущность, существующую в единственном экземпляре
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, RSATom, Вы писали: RSA>>Ок, приведу пример. В программе могут быть как минимум следующие глобальные (по сути) сущности: RSA>>1) Gui Application object — т.е. нечто что необходимо для создания окошек/контролов __>в нормально спроектированном приложении окошки-контролы создаются не из логики, а только из view, а view по сути и является таким обьектом. но так как мы должны иметь свое view для модели, то нелогично не самом деле иметь view-синглон
view тоже необходимо где то создавать (а при создании нужны некие параметры), если количество view переваливает за некое критическое количество, то их так же приходится группировать, а в эту группу точно так же существует необходимость передачи неких параметров.
RSA>>2) Logger Object — из названия понятно, для ведения логов. __>да, обычно это синглтон. точнее, это вообще обычно макрос в С++, в явном виде никто с синглтоном не работает
т.е. получается уже как минимум 2 синглетона являются приемлимыми? т.е. тезис о том что синглетон — это "абсолютно зло" уже не работает?
RSA>>3) Config Object — для доступа к текущей конфигурации приложения. __>"конфиг" это криво реализованная сериализация. не надо на самом деле никаких конфигов городить в нормально спроектированном приложении или по крайней мере это не должно быть синглтоном
Не о сериализации разговор, а о неких параметрах влияющих на логику работы приложения. Частный пример — настройки задаваемые пользователем. Кстати говоря, Сonfig object зачастую тоже может быть не один, т.к. разные части приложения могут быть абсолютно не связаны, и глупо их связывать через общий config
RSA>>Если не использовать синглетоны — огромное количество функций/конструкторов должены будет получать некоторые/все из этих сущностей, а так же передавать далее. Кроме того, в экземлярах классов нужные сущности придется хранить, а это увеличиит каждый экземпляр класса на sizeof(void*) * n, где n = 1..3 __>да, это одна из первых проблем новичков. поэтому, как классическое решение, возникают контроллеры сущностей и единая точка доступа к контроллерам приложения, которая да, является синглтоном. но это один синглтон на приложение, а не куча на каждую сущность, существующую в единственном экземпляре
Опять же, получается что синглетоны имеют право на сущестование? Естествено применять их нужно с умом, но тем не менее?
Здравствуйте, Аноним, Вы писали:
RSA>>>когда однажды, количество аргументов некоторой функции перевалит за десяток, синглетон перестанет выглядеть такой уж страшной вещью... I>>Когда количесттво аргументов увеличивается, нужно свернуть аргументы упаковывая в отдельный класс. А>Эта мантра не поможет, ибо конструктор(=инициализация) упаковки никуда не денется.
Речь не о том, чтобы просто упаковать параметры и делать это при каждом вызове. Если функция принимает много параметров, то имеется вероятность, что это вылезает наружу пропущенная абстракция. А раз это полноценная абстракция, то это уже нечто большее, чем тупая структура для передачи данных и вовсе не факт, что мы ее будем создавать при каждом вызове нашей функции.
Гудбай.
