Процесс во всех трех случаях один и никакого MDI.

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

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

Да я как бы и так в курсе про low coupling & high cohesion , ничего нового я там не прочитаю.

Давай я лучше разжую тебе то, что по твоей ссылке написано:

Связанность сообщений (низкая)
Это наислабейший тип связанности. Он может быть достигнут децентрализацией состояний (как в объектах) и коммуникацией компонентов через параметры или передачу сообщений

Так вот колбэки — это и есть один из механизмов «передачи сообщений», который, согласно твоей ссылке, позволяет достичь желанной низкой связности.

За одно, раз ты сторонник хранения конфига с синглтоне, прочитай по своей ссылке внимательно еще вот это:

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

Это как раз и есть твой синглтон (он мало чем отличается от глобальной переменной, верно?).

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

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

если и это религия не позволяет, то для случая запросов будет...

при моём подходе:

while (true) {
    ProcessRequest();
}

void ProcessRequest() {
    const std::string &param = Config::GetValue("param");
}

при твоём подходе:

while (true) {
    ProcessRequest(config);
}

void ProcessRequest(const Config &config) {
    const std::string &param = config.GetValue("param");
}

потому что снаружи всё равно виден синглтон.

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

Объясни, как ты снаружи отличаешь синглтон от всего остального? Смысл синглтона скрыть от вызывающего кода обращение к единственному инстансу. Если ты снаружи можешь отличить синглтон от остального, значит у тебя не сиглтон, а банальная глобальная переменная.

значит у тебя не сиглтон, а банальная глобальная переменная.

lol, так это практически одно и то же ведь, только названия разные )

в случае конфигурации общая связанность никуда не девается: все заинтересованные объекты хранят ссылку на конфиг.

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

нет. я нашёл в википедии статью про связанность специально для тебя.

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

Уровень абстракции разный. В случае с синглтоном можно безболезненно заменить реализацию на другую.

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

А чё, можно несколько синглтонов замутить? Расскажи-ка как.

почему ты это спрашиваешь у меня?

В случае с синглтоном можно безболезненно заменить реализацию на другую.

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

почему ты это спрашиваешь у меня?

Потому что возле анона нет IP-адреса...

лолшто?

что помешает мне заменить реализацию такой штуки: Config g_config; ?

что помешает мне

this:

реализацию

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

мы с тобой под реализацией явно понимаем что-то разное... если class Config, у него есть статический метод Instance() (который, кстати, может отдавать разные инстансы хоть по рандому). я положил на него болт и объявил глобальную переменную типа Config (допустим, это возможно). почему отказ от использования одного статического метода мешает мне менять реализацию?

т.е. в принципе нет главного окна, но это скорее исключение из правила

Как-то получается, что все удобные приложения - исключения, может правило стоит пересмотреть?

Но что ты вкладываешь в понятие много окон в IDE, мне не понять.

По окну на проект, внутри проекта действительно MDI, но это тут не имеет значения.

Все места в коде, обращавшиеся к сессии, остались не тронутыми

мде. что-то с единством терминологии у нас, коллеги, не то :)

Я умею вот так:

>>> v1 = {'a': 1, 'b': 2}
>>> v2 = v1
>>> v1['c'] = 3
>>> v2
{'c': 3, 'a': 1, 'b': 2}

у него есть статический метод Instance() (который, кстати, может отдавать разные инстансы хоть по рандому

Можно вот с этого места поподробней...?

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

В этом случае получится упомянутый мною квадроцикл. Тебе ничего не мешает, да.

Конечно, ничего.

безболезненно

Как-то получается, что все удобные приложения - исключения, может правило стоит пересмотреть?

Аргументация на уровне. Закежь список то, а?

По окну на проект, внутри проекта действительно MDI, но это тут не имеет значения.

Шта млио значит по окну на проект? Покажи скриншот или что-нибудь, что ты имеешь этим ввиду? Я на 80% уверен, что это будет либо MDI, либо второй процесс.

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

Вот ты упоротый, на, почитай что производительность пишет, если мне не веришь

http://www.jetbrains.com/idea/webhelp/opening-multiple-projects.html

Можешь даже скачать и скриншотов наделать, а то мне с ведроида неудобно.

All the projects run in the same instance of IntelliJ IDEA and use the same memory space.

В данном случае тот instance Main Window, о котором я упоминал будет сама IntelliJ IDEA. Т.е. у них это реализовано таким образом. Я к тому, что не все так делают, но один singleton, который всем управляет, обычно присутствует же.

код выглядит кривовато

Действительно. Твой код выглядит кривовато.

Ну да, только тот, кто писал тот класс, таким образом сделал его синглтоном, т.к. создавать два экземпляра не имеет смысла. Т.е. это не синглтон, но ведёт себя именно так.

Есть еще один пример из так любимого на ЛОРе Erlang'a - Supervisor

Это ещё почему? Что мешает сделать supervisor:start_link(myapp_su, Args) пять раз с разными аргументами и получить пять разных супервайзеров?

MainWindow это пример не удачный. Бери шире - Application.

В данном случае тот instance Main Window, о котором я упоминал будет сама IntelliJ IDEA.

Нет никакого Main Window там, все окна с проектами равнозначны и других окон нет. А то что ты привел - это про то что процесс (jvm) один на все окна.

Т.е. это не синглтон, но ведёт себя именно так.

Сомневаюсь коллега, он ведёт себя не совсем как синглтон, но попахивает изрядно.

MainWindow это пример не удачный. Бери шире - Application.

О. Два чая этому господину, и булочку. Но как я заметил, у Application может быть всего лишь один Main Window, потому как больше иметь может не иметь смысла.

Нет никакого Main Window там, все окна с проектами равнозначны и других окон нет.

Да, графического нет в этом смысле. Оно будет называться Application, как уже заметили.

Что мешает сделать supervisor:start_link(myapp_su, Args) пять раз с разными аргументами и получить пять разных супервайзеров?

Писать говнокод никто никому не мешает. Если твой module_sup:start_link() делает что-то кроме запуска одного супервизора, то похвалить тебя будет не за что.

Ну может может, а может и нет. Но только из-за того, что qapplication синглтон, про бескостыльную разработку либ, использующих кутишные сигналы можно забыть. Тут вот примерчик http://stackoverflow.com/questions/1786438/qt-library-event-loop-problems

В принципе даже не понятно зачем вручную дергать кучу supervisor:start_link - кучу неудобств может создать на ровном месте.

Ну там чувак захотел заюзать Qt не в кутешном приложении...

Ты всё путаешь. Обрати внимание на Args, они могут передаваться процессам под супервайзером (что чаще всего и бывает) и это будет определять их поведение.

Кроме того, как ты собираешься считать супервайзер сингтоном, если сам же утверждаешь, что „Создавать all-in-one supervisor будет только идиот“?

Не, он хотел сделать длл в котором используются кутишные штуки, но при этом так, что бы длл можно было юзать как из кутишных так и не кутишных приложений. Мне когда-то тоже такая идея приходила в голову. Чего-то даже заработало, но больше я таким заниматься не стану. И всё из-за того, что qapp - синглтон. Понятно, что это наверняка обусловленно какими-то архитектурными или техническими причинами, но как результат имеем „границы применимости“ кутей. Границы может и преодолимые, но неприятные.

И всё из-за того, что qapp - синглтон. Понятно, что это наверняка обусловленно какими-то архитектурными или техническими причинами, но как результат имеем „границы применимости“ кутей. Границы может и преодолимые, но неприятные.

Ну как там написано, нужно просто дать qapp'у главный тред. Я тоже не в курсе архитектурных ограничений.

по-моему мы друг-друга не понимаем. есть class Config, у него есть какой-нибудь публичный конструктор и static Config &Instance(). какая разница как я его буду использовать?

так:

Config config;

Config &config = Config::Instance();

конструктор которого возвращает всегда один и тот же инстанс

это как?

а то....

....надо

Window *CreateWindow(Window *parent,
                     int left_x, int left_y,
                     int right_x, int right_y,
                     Handler *draw_handler,
                     Handler *ok_button_handler,
                     Handler *cancel_button_handler);

тип окошка забыл. И МБ_ОК тоже добавь.

Я знаю как работает супервизор :) Я говорю о том что в OTP принято инкапсулировать в модуле-супервизоре строго определенную логику: http_acceptor_sup работает только с процессами acceptor'ами, http_worker_sup - только воркерами, http_sup - мониторит http_acceptor_sup и http_worker_sup. Каждый супервизор занимается строго определенными задачами, да, через http_acceptor_sup можно извратится и запускать воркеры, но это серьезный косяк в дизайне.

Ну правильно. И теперь, допустим, тебе надо запустить два http_acceptor_sup, которые слушают на разных портах. Для примера 80 и 8080.

Например, так:

>>> class Singleton:
...     _instance = None
...     def __new__(cls):
...         if not cls._instance:
...             cls._instance = super().__new__(cls)
...         return cls._instance
... 
>>> a = Singleton()
>>> b = Singleton()
>>> a is b
True