Вопрос по архитектуре приложения. Медиатор

[Igors]

Мне кажется пример с кнопками и метками не совсем жизненный, и в принципе задача довольно простая чтобы с ней заморачиваться.

Ну простой - да, а в жизненности ему не откажешь.

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

Паттерн - это (типовой) прием(чик), поэтому не надо ожидать от него решения глобальных задач. В сложных случаях разрабатывается/утверждается "интерфейс" каждого модуля, т.е. что он должен знать и чего не должен. Это часто становится предметом жарких споров. За каждую "слабосвязность" (гибкость) приходится платить промежуточными классами которые часто оказываются под ударом. Некоторые верят что есть чудесный способ (я нет). Напр манечка "импорт/запрос интерфейса" загубила не один проект..

Так решение о применении каждого конкретного паттерна должно основываться, исходя из условий задачи. А Вы уже ведёте речь о повсеместном применении. Паттерн медиатора, о котором эта тема, сам по себе не предполагает собственное использование со всеми подряд QPushButton'ами и т.п., но лишь в том случае, когда сгруппированный функционал взаимодействия между объектами классов рационально вынести в посредника. Другими словами, если мы и определили класс-наследник для некоторых QPushButton, то это не значит, что всех подряд надо гнать под одну гребёнку. Я думаю так.

Я не вижу никакой ошибки в Ваших рассуждениях, но налицо разрыв слова и дела (не у Вас лично, а вообще в теме). Пока "взагалi" - все чудесно, и ссылки сыпятся, и на пальцах запросто и.т.п. Но вот доходит до кода (маленького) - и куда что девается.. То класс явно притянутый за уши, то вообще "ах это не тот паттерн", зачем нужно и где выигрыш/резон того же медиатора - ни одного внятного примера  

И пошел поток бреда:

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

[nata267]

Не, я бы всё же назвал тему как то так: К вопросу о паттерне Медиатор, или О особенностях использования Медиатора или...
А так название темы совсем не пойми о чём.. В смысле не отражает суть вопроса, имхо(

Наталья, не слушайте Вы никого, кто говорит, что это захламит ваш чердак и потом найти нужную вещь будет нереально.. Это всё бред) Холмс имел в виду совсем другое) Очень хорошо, что вы интересуетесь и изучаете паттерны, ищите, блуждаете.. Всё это во благо) Кто ищет - вынужден блуждать)

ЗЫ
А если кто-то будет наезжать здесь, скажите, что Вы человек Макса))     

)) пока никто особо не наезжал, хотя вначале ожидала много критики

[alexis031182]

...
ЗЫ
А если кто-то будет наезжать здесь, скажите, что Вы человек Макса))     

Тогда уж лучше "от Макса"

У входа в гостиницу:
- Эй, мужики, вы куда?! Вам сюда нельзя.
- Мы от Саныча.
- Какого такого Саныча?
- Ты чё, Саныча не знаешь?
- Нет... Проходите.

[alexis031182]

)) пока никто особо не наезжал, хотя вначале ожидала много критики

Самим бы разобраться прежде чем начинать критиковать

[alexis031182]

Я не вижу никакой ошибки в Ваших рассуждениях, но налицо разрыв слова и дела (не у Вас лично, а вообще в теме). Пока "взагалi" - все чудесно, и ссылки сыпятся, и на пальцах запросто и.т.п. Но вот доходит до кода (маленького) - и куда что девается.. То класс явно притянутый за уши, то вообще "ах это не тот паттерн", зачем нужно и где выигрыш/резон того же медиатора - ни одного внятного примера  

Честно говоря, пришлось задуматься над Вашими словами по поводу нерациональности наследования от того же QPushButton. Спустя время, дошло, что можно вместо наследования применить обратный метод - декорирование. То есть, обслуживаемый класс помещаем в некий класс Декоратор, в котором и будет содержаться указатель на медиатор и указатель на обслуживаемый объект. Думаю, это должно помочь решить возникшую проблему.

И пошел поток бреда:

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

Умение корректно "задавить" оппонента в споре уважается несколько больше. На иные методы - другие реверансы. Да просто как-то ни к чему такое...

[Igors]

Наталья, не слушайте Вы никого, кто говорит, что это захламит ваш чердак и потом найти нужную вещь будет нереально.. Это всё бред) Холмс имел в виду совсем другое) Очень хорошо, что вы интересуетесь и изучаете паттерны, ищите, блуждаете.. Всё это во благо) Кто ищет - вынужден блуждать)

А Вы тут из себя не разыгрывайте старичка (отдыхающего на завалинке) а активно подключайтесь 

Честно говоря, пришлось задуматься над Вашими словами по поводу нерациональности наследования от того же QPushButton. Спустя время, дошло, что можно вместо наследования применить обратный метод - декорирование. То есть, обслуживаемый класс помещаем в некий класс Декоратор, в котором и будет содержаться указатель на медиатор и указатель на обслуживаемый объект. Думаю, это должно помочь решить возникшую проблему.

Я не вижу зачем нужен этот указатель. Если "с контролом что-то случилось" - везде родитель получит управление (через сигналы или как - детали). Также не вижу ничего против обработки (содержательных действий) в окне-родителе. Оно ведь все контролы и создавало, ну ему и карты в руки

[alexis031182]

Я не вижу зачем нужен этот указатель. Если "с контролом что-то случилось" - везде родитель получит управление (через сигналы или как - детали). Также не вижу ничего против обработки (содержательных действий) в окне-родителе. Оно ведь все контролы и создавало, ну ему и карты в руки

Да нет, Ваше решение отличное, применительно к обсуждаемому нами маленькому примеру. Но я всё размышляю в сторону своего проекта вебсервера. Когда я к epoll-событиям подключил сигнал-слоты и QEvent, программа стала работать значительно медленнее. Пробовал по всякому извращаться, но скорости не прибавилось. Поэтому я задумался о решении, которое на уровне затрат обычного вызова функции позволит столь же гибко управлять всеми процессами взаимосвязанных объектов, как это сделано в случае событийной модели Qt.

[m_ax]

Наталья, не слушайте Вы никого, кто говорит, что это захламит ваш чердак и потом найти нужную вещь будет нереально.. Это всё бред) Холмс имел в виду совсем другое) Очень хорошо, что вы интересуетесь и изучаете паттерны, ищите, блуждаете.. Всё это во благо) Кто ищет - вынужден блуждать)

А Вы тут из себя не разыгрывайте старичка (отдыхающего на завалинке) а активно подключайтесь  

Нет, я пообещал себе особо не вмешиваться.. У меня сейчас типа творческий кризис..((
Но про паттерн Медиатр я почитал.. И, кстатии, мне кажется вы его тож неявно использовали.. (когда-то)
Я сам его мыслил использовать, когда подумывал о написании одной модели (аналога QGrapicsScene/Model).. А потом подумал: да нафига мне это...

Моя мысль в том, что паттерны прогр. -  всё же, не на пустом месте придумали) И, наверное, всё же есть смысл, перед тем как воять свой велосипед, посмотреть, как же уже другие решали подобные проблемс)
Что в этом преступного?      
 

[m_ax]

Кстати, BRE куда то пропал.. Давно его уже не видно и не слышно..

[Igors]

И, кстатии, мне кажется вы его тож неявно использовали.. (когда-то)

Если Вы имеете ввиду старую тему "переходничок", то это наверное "adapter" - хотя знаток паттернов из меня никакой

Моя мысль в том, что паттерны прогр. -  всё же, не на пустом месте придумали) И, наверное, всё же есть смысл, перед тем как воять свой велосипед, посмотреть, как же уже другие решали подобные проблемс)
Что в этом преступного?      

Так вот и смотрим - но это не значит "понимаем". А тупенько копировать - не всем хочется

Для того наверно чтобы все время не создавать объект QSettings для каждого окна, а чтобы делать это централизовано. В менеджере настроек сразу определяется куда будут записываться настройки, а также происходит инициализация объекта QSettings:
m_settings(qApp->organizationName(), qApp->applicationName())
Кроме того мы сможем менять поведение менеджера на специфичесое для данного проекта.

Хмм... ну может и так, не исключено. Однако такой подход предвзятен, мы как бы "подгоняем задачу под паттерн" - а должно быть наоборот.