Паттерн наблюдатель

[Igors]

А за сингетон, да в таком случае, нужно сразу в разносчика кофе переводить.

Заучив правило (напр "синглтон = плохо"), догматик неуклонно ему следует - таково уж его мЫшление  Бедный синглтон плох везде и всегда - потому что так заучили.

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

[Old]

Заучив правило (напр "синглтон = плохо"), догматик неуклонно ему следует - таково уж его мЫшление   Бедный синглтон плох везде и всегда - потому что так заучили.

А что это за правило такое: "синглетон = плохо"? Вы опять читали хабр?

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

А для чего его передавать в десятки функций? Да еще и сделать его синглетоном, что бы не передавать на него ссылки? Это уже какое-то дно.
Синглетон - это объект, который может существовать ТОЛЬКО в одном экземпляре. Это не в коем случае, не удобная точка доступа к объекту. А диалогов прогресса может быть много.
А решается это все несколькими сигналами, которые методы объекта исполнителя будут посылать и объектом диалога, который их будет обрабатывать.
Послал объект исполнитель сигнал started, в котором передал общее количество операций, диалог настроил общий бар. Послал объект исполнитель сигнал startedStage с длительностью конкретного этапа, диалог создал бар для этапа, пришел сигнал finishedStage - удалил бар для законченного этапа.
Вы не свои сообщения читаете, пытаетесь их понять? Я это уже описывал выше.

[Bepec]

Igors - гениально. У вас в вашей программе будет.
1 исходные данные в системе обработки.
1 копия данных в синглтоне.
1 копия данных в каждом индикаторе/прогрессбаре.

Вопрос - где лишнее?

[Racheengel]

Хорошо... расширим сигнал Done до 2 параметров, 1 это общий процент, 2 это процент загрузки текущего файла...

А какое имя у "текущего файла"?
Мы передали загрузчику файлов список имен. Как нам узнать какой файл он сейчас загружет?

Изначальное ТЗ такого требования не содержало.
Но если хотите велик на все случаи жизни, то ради бога. ..
Эмитируем из загрузчика onProgress (this).
Гуй по получению указателя на класс загрузки обращается к нему через публичный интерфейс и получает все необходимые данные.
Только в обоих случаях придется все время что то где то дописывать, либо параметры сигнала расширять, либо интерфейс загрузчика. Где мы выигрываем?

[Racheengel]

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

[Old]

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

Потому что у Igors идея обратная, дать всем возможность управлять объектом ProgressDialog.

[Old]

Эмитируем из загрузчика onProgress (this).

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

[Igors]

А решается это все несколькими сигналами, которые методы объекта исполнителя будут посылать и объектом диалога, который их будет обрабатывать.
Послал объект исполнитель сигнал started, в котором передал общее количество операций, диалог настроил общий бар. Послал объект исполнитель сигнал startedStage с длительностью конкретного этапа, диалог создал бар для этапа, пришел сигнал finishedStage - удалил бар для законченного этапа.

Вот напр, следуя Вашим советам, мы написали

Код

C++ (Qt)
emit startedStage(fileName, 0, fileSize);
...
emit updateStage(fileName, 1);
...
emit finishedStage(fileName);
 

И типа "все хорошо", никаких зависимостей (якобы) нет, знай посылай сигналы - и дело в шляпе. Так это в теории Ничего хорошего здесь нет. Индикаторы могут создаваться очень многими классами, которым QObject нужен как собаке пятая нога, а то и просто ф-циями. Придется делать какой-то левый QObject (тем же синглтоном?) или "смешиваться" с boost::signal (число энтузиастов сокращается).

Но то еще цветочки. Бросается в глаза уязвимость посылки - по имени файла (а как еще?). "Кому" это шлется? Сугубо частный случай: заведем сигнал для счетчика файлов и другой для текущего файла, - ну общность и расширяемость такого решения нулевые. Заметим также что finishedStage придется кропотливо отслеживать или навешивать какой-то "scoped". А зависимости никуда не делись - только теперь они не объявлены ясно в интерфейсе, а раскиданы там и сям по слотам и сигналам.

Что же хорошего? Да ничего, слепое следование паттерну который считается "хорошим" 

И вообще, неплохо бы знать "предмет", или хотя бы иметь о нем понятие.

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

Ага, щас, побежал создавать/удалять/настраивать. Операции с длительностью меньше заданной (напр 0.5 сек) вообще не должны показываться, и удалять из UI надо c задержкой чтобы заново всякий раз не вставлять т.е. не мельтешить с диалогом. А значит исполнитель должен хранить список активных и по Update уже рулить всеми.

[Bepec]

Igors во всей красе...
No comments.

[Old]

И типа "все хорошо", никаких зависимостей (якобы) нет, знай посылай сигналы - и дело в шляпе. Так это в теории Ничего хорошего здесь нет. Индикаторы могут создаваться очень многими классами, которым QObject нужен как собаке пятая нога, а то и просто ф-циями. Придется делать какой-то левый QObject (тем же синглтоном?) или "смешиваться" с boost::signal (число энтузиастов сокращается).

Но то еще цветочки. Бросается в глаза уязвимость посылки - по имени файла (а как еще?). "Кому" это шлется? Сугубо частный случай: заведем сигнал для счетчика файлов и другой для текущего файла, - ну общность и расширяемость такого решения нулевые. Заметим также что finishedStage придется кропотливо отслеживать или навешивать какой-то "scoped". А зависимости никуда не делись - только теперь они не объявлены ясно в интерфейсе, а раскиданы там и сям по слотам и сигналам.

Где что раскидано? Какие зависимости?
Вы сейчас выдали кучу голословных проблем, которые есть в вашем восприятии. Кодом доказывайте, кодом. Где там раскиданы зависимости.
Так же не понятно для чего в очередной раз притянуты сигналы Qt и буста. Не хотите не используйте.

Что же хорошего? Да ничего, слепое следование паттерну который считается "хорошим" 

Какому паттерну? Вы мне хоть скажите, каким патерном я здесь пользуюсь.

И вообще, неплохо бы знать "предмет", или хотя бы иметь о нем понятие.

Я то знаю, не понятно вы тут что делаете?

Ага, щас, побежал создавать/удалять/настраивать. Операции с длительностью меньше заданной (напр 0.5 сек) вообще не должны показываться, и удалять из UI надо c задержкой чтобы заново всякий раз не вставлять т.е. не мельтешить с диалогом.

Так кто вам мешает сделать все так как вы описали. Правда не очень понятно откуда взялись эти "странные требования".

А значит исполнитель должен хранить список активных и по Update уже рулить всеми.

Для чего ему этот идиотизм. Исполнитель должен хорошо работу свою работать, а не думать как там ему диалоги обновлять, тем более никакого ГУЯ может не быть вообще. Опять все притащили в класс MainWindow.

[m_ax]

Перечитав 3 страницы я так и не понял, какой основной тезис у товарища igors.. В чём, собственно преимущества С-подхода по сравнению с патерном обсёрвера? Не, ну реально, может я, как всегда не допонимаю, но причём здесь конкретнгые реализации диалогов и т.д.. Речь о архитектуре, как поставил вопрос ТС. Какой механизм наиболее гибок и независим для данной ситуации.   Т.е. у нас есть некая сущьность, которая выполняет свою работу - всё. Мы не хотим 100500 раз вмешиваться в её код) Как по мне, то основная проблема здесь в выделдении минимально необходимого интерфейса этого файллоудера с внешним миром.) В чём проблема?) 

[Old]

Как по мне, то основная проблема здесь в выделдении минимально необходимого интерфейса этого файллоудера с внешним миром.) В чём проблема?)  

Какой fileloader, он уходит на второй план, а на первый у нас выходит диалог прогресса.
Для него мы искаверкаем ядро, "познакомим" с ним всех, кого только можно и научим fileloader его правильно вызывать, даже если диалог прогресса в большинстве случаев нафик никому будет не нужен. В общем, у нас новый MainWindow с именем ProgressDialog.

Очередной пробой дна после Переходничка.  

[m_ax]

Как по мне, то основная проблема здесь в выделдении минимально необходимого интерфейса этого файллоудера с внешним миром.) В чём проблема?) 

Какой fileloader, он уходит на второй план, а на первый у нас выходит диалог прогресса.
Для него мы искаверкаем ядро, "познакомим" с ним всех, кого только можно и научим fileloader его правильно вызывать, даже если диалог прогресса в большинстве случаев нафик никому будет не нужен. В общем, у нас новый MainWindow с именем ProgressDialog.

Очередной пробой дна после Переходничка. 

Вот вот, какое то гипертрофированое раздувание из мухи слона) И я так и не понял, почему, конкрено, патерн обсёрвер плох в данной ситуации? 

[Old]

Вот вот, какое то гипертрофированое раздувание из мухи слона) И я так и не понял, почему, конкрено, патерн обсёрвер плох в данной ситуации? 

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

[m_ax]

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

Ну всё как обычно, да