Я в браузере, почтовике и IDE регулярно делаю больше 1 окна

Виноват не singleton, а singleton, поставленный не к месту. И вообще, нельзя предусмотреть все хотелки или «повеления рыночной необходимости». Паттерны — это общепринятые best practics, а делать приложения гибкими должен программист.

в OnSettingsChanged()

ты уже понял какую ерунду написал?

Нет, не понял.

Если что, кейс такой: настройки меняются прямо во время работы твоего демона. Узнавание о том, что настройки изменились, возложено на специализированный механизм (то ли он за sighup через пайпу поллит, то ли от веб-морды по rpc пинок получает, это уже не важно). Вот этот механизм и дергает OnSettingsChanged() у всех, кто должен применить новые настройки.

Ok, давай так. У приложения есть Main Window. Когда тебе может захотеться 2 Main Window?

тогда, когда это XMPP чат, который основное время сидит в трее, а окна с ростерами, чатами и ви-кардами создаёт по надобности.

и да, термин «Main Window» тут (в Gtk) не уместен.

Виноват не singleton, а singleton, поставленный не к месту.

Речь о том, что singleton не к месту почти всегда. Единственный условно-адекватный пример синглетона, который всплыл за все три страницы срача, это логгер.

Паттерны — это общепринятые best practics, а делать приложения гибкими должен программист.

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

Единственный условно-адекватный пример синглетона, который всплыл за все три страницы срача, это логгер.

Есть еще один пример из так любимого на ЛОРе Erlang'a - Supervisor. По сути это синглтон-сущность, что абсолютно логично: ну не должно в программе быть два супервизора для, например, БД.

не должно в программе быть два супервизора для, например, БД.

не должно тебя и таких как ты быть в программировании.

умышленно убивать гибкость - пора за это осуждать и предавать анафеме!

Зато потом, когда у тебя вдруг появятся другие хотелки

Ты переписываешь реализацию класса с синглтона на другую. Все. Остальной код работает как и прежде.

Я вот не пойму, откуда в треде взялось требование переписывать код, обращающийся к синглтону, когда меняются требования. Ведь синглтон - это шаблон реализации класса, который и есть абстракция, реализацию которой можно менять в зависимости от требований так, чтобы не ломать зависимый код. А если вам пришлось переписать класс, а потом еще переписать весь остальной код, то либо требования на столько изменились (и вам в любом случае пришлось бы менять остальной код), либо вы херово спроектировали подсистему.
В качестве банального примера на ум приходит реализация сессий в веб-приложении, которая встречалась на практике. Изначально реализовали синглтон для обращения к БД, через который работали все сессии. Возросли требования - переписали синглтон, на мультитон (узанл название паттерна из этого треда, лол), который возвращает экземпляр подключения из пула свободных сессий. При этом изменилась реализация класса сессий. Можно было, конечно, изначально реализовать пул сессий, только синглотон проще в реализации, а зачем усложнять систему, если не понятно, потребуется ли заточка на производительность.

Какая гибкость в супервизоре тебе нужна? Настроил политику перезапуска сервиса и забыл об этом супервизоре.Создавать all-in-one supervisor будет только идиот.

OnSettingsChanged() у всех, кто должен применить новые настройки

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

мало того, они должны наследоваться от одного интерфейса... все (sic!)

Мультитон и пул - очень слабо связанные вещи.

Если в программе у менеджера конфигурации реализован сигнально/слотовый механизм, то нужно только хранить подписчиков на сигналы.

Что значит знать обо всех? Навешивание колбеков - это знание обо всех?

у менеджера конфигурации реализован сигнально/слотовый механизм

а куда подписываться, они узнают по параметру конструктора, ага.

лучше пиши на эрланге :)

Я в браузере, почтовике и IDE регулярно делаю больше 1 окна

Ты смешал в кашу MDI, singleton и несколько процессов.

Навешивание колбеков - это знание обо всех?

хуже того, неявное.

религия не позволяет не хотеть знать о том, что конфигурация может обновляться?

Да, я немного наврал. Переписали действительно на пул. Но я видел реализацию где сессия оставалась висеть в приложении (с подключением к БД) и пользователь переиспользовал ее при следующем запросе, там как раз было key (sid) - value (данные сессии), а это, как я понимаю, и есть мультитон. Я к тому, что синглтон в данном случае могли переписать на все, что угодно, хоть на генерацию произвольных сессионных данных, на остальной код это никак не влияло.

а куда подписываться, они узнают по параметру конструктора, ага

Что в случае с синглтоном, что с мультитоном у тебя есть объект хранящий настройки - на него и подписывайся. А что уж он делает с подпиской - обслуживает сам или форвардит ее куда-нибудь - тебя не касается.

хуже того, неявное.

А если назвать это абстрагированием, становится лучше?

религия не позволяет не хотеть знать о том, что конфигурация может обновляться?

Да мне в общем-то не интересен пример именно с настройками, у меня возник вопрос именно о знании обо всех.

религия не позволяет не хотеть знать о том, что конфигурация может обновляться?

Требования может такие: не перезапускать сервис при обновлении его конфигурации. Может тут кластер числа крошит, а ты хочешь его перезапустить потому что путь к логам поправил в настройках?

у тебя есть объект хранящий настройки - на него и подписывайся

у тебя messaging головного мозга.

как по мне, хоть Config::GetValue(key), хоть config.GetValue(key) — без разницы. но. меньше параметров конструктора — приятнее чувству прекрасного.

см ниже:

singleton пащиму? (комментарий)

м?

у меня возник вопрос именно о знании обо всех

если возникают такие вопросы, есть повод задуматься о своей квалификации

https://ru.wikipedia.org/wiki/Связанность_(программирование)

у тебя messaging головного мозга.

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

такое обновление может в итоге все поломать и сервис рухнет не рассматриваем

прохладная история :)

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

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

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

отсюда: singleton пащиму? (комментарий)

у меня возник вопрос именно о знании обо всех

отсюда: singleton пащиму? (комментарий)

но его можно расположить и на нижнем

взаимоисключающие параграфы детектед.

Ты меня запутать пытаешься? Глядя на пример кода, ты сказал, что класс настроек должен знать обо всех, кто к нему обращается. Мне не понятно, как ты сделал такой вывод. Я тот код понял как навешивание колбэка. Приведенная тобой ссылка говорит лишь о том, что реализацию можно расположить на любом уровне, а колбэки стремятся к нижнему уровню, что хорошо. Говорит о том, что это плохо можно только, если расположить реализацию на верхних уровнях. Но кто в этом виноват?

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

у тебя в программе должна быть какая-то хрень, которая знает обо всех объектах, требующих конфига, в системе.

Она знает только о том интерфейсе, от которого все объекты унаследовались. О самих объектах — не знает ничегошеньки, а только связана с ними во время выполнения. Observer pattern.

мало того, они должны наследоваться от одного интерфейса... все

Ну а куда деваться?

Ну а куда деваться?

не лохматить бабушку и назвать конфигурацию тем, чем она на самом деле является (синглтоном)?

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

суй ссылку в конструкторы

Это само собой. Но это не отвечает на вопрос: как объект узнает о том, что его настройки изменились?

не лохматить бабушку и назвать конфигурацию тем, чем она на самом деле является (синглтоном)?

Опять же таки, зависит от аппликухи. Если это десктопное приложение, то конфигурация одна. Если это сложная система с конфигурацией в БД и возможностью откатов, то уже не синглтон.

Предлагаю тебе как-нибудь более развернуто ответить

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

программа должна в идеале иметь вид дерева (леса), а не циклического графа.

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

почему?

интерфейс — синглтон. что у него под капотом — дело десятое.

см мои предыдущие комментарии

когда готов к изменению конфигурации — перечитай её из объекта конфига. когда не готов — пользуйся локальными копиями. всяко проще чем защищаться от возможных последствий при асинхронном событии.

когда готов к изменению конфигурации — перечитай её из объекта конфига.

Допустим, готов почти всегда. Сколько миллионов раз в секунду прикажешь её перечитывать в мою локальную реплику?

Если синглтон отвечает за конфигурацию, то как ты его сменишь (откатишься на предыдущую, допустим)?

интерфейс — синглтон

Я этого не понимаю. Интерфейс - это то, с чем взаимодействует вызывающий код. Какая ему нахер разница, синглтон там или нет? Это на совести проектировщика. Синглтон - это шаблон реализации, почему вы называете его интерфейсом?

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

Бгг, ты ещё на кофейной гуще погадай.

Мне кажется ошибочно говорить «тут мы делаем синглтон» и подгонять всю реализацию под это решение. Правильнее, на мой взгляд, реализовывать в зависимости от требований, а уже получившееся обзывать сиглтоном, мультитоном или что у вас там получилось. Отсюда и все разногласия.

те объекты, которые дёргаются миллион раз в секунду, зависят максимум от нескольких параметров конфига (чаще совсем не зависят — не их это дело). ты, которые дёргаются тысячи — уже зависят, но далеко не от всего конфига. сколько стоит присвоение нескольких константных ссылок?

если используемый в «горячем» месте кусок управляется таким развесистым куском конфигурации, что его дорого скопировать, то возникает сомнение что он успевает заниматься чем-то полезным.

в некоторых аналогичных случаях (конечно, не на уровне конфигурации всей программы) я применял версионирование.

почитай мою ссылку на википедию. узнаешь много нового и интересного.

ты зачем делаешь из своих программ клубок?

дёрну за метод Update() того же синглтона? а он уже сам решит что это для него значит.

завязываем с тупняком...

То есть ты предлагаешь всякий раз перед тем, как что-либо сделать, перечитывать конфиг? Это ж у тебя весь код будет засран вызовами ReloadSettings().

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

P.S. отвечал анону, хотя на самом деле это обращение всем участникам дискуссии.

это значит, что я не дёргаю Config::login. вместо этого Config::GetLogin(), который может его в зависимости от погоды на марсе хоть из базы тянуть, хоть рандомом генерить, хоть проксировать на созданный по желанию левой пятки подсистемы управления заказами объект. мне реализация этого синглтона строго параллельна.

*кэшировать его или считывать каждый раз

Процесс во всех трех случаях один и никакого MDI. может это ты что-то напутал?

мне реализация этого синглтона строго параллельна.

реализация
синглтона

Так там уже может быт не синглтон. Почему название осталось?

сессия оставалась висеть в приложении (с подключением к БД)

Неэффективно же (любой школьник DOS может устроить), но ок, это уже похоже.