Russian Qt Forum
Ноябрь 24, 2024, 03:59 *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

Войти
 
  Начало   Форум  WIKI (Вики)FAQ Помощь Поиск Войти Регистрация  

Страниц: 1 ... 3 4 [5]   Вниз
  Печать  
Автор Тема: Вопрос по архитектуре приложения. Медиатор  (Прочитано 35645 раз)
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #60 : Июнь 08, 2012, 20:44 »

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

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

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

И пошел поток бреда:
Дмитрий, чем больше Вы хамите, тем яснее всем что своих мыслей у Вас нет, а попытки скрыть это кучей прочитанного (но никак не осмысленного) выглядят убого. Впредь отвечать Вам просто не буду, нет смысла тратить время на хамло
Записан
nata267
Гость
« Ответ #61 : Июнь 08, 2012, 20:53 »

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

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

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

)) пока никто особо не наезжал, хотя вначале ожидала много критики
Записан
alexis031182
Гость
« Ответ #62 : Июнь 08, 2012, 20:54 »

...
ЗЫ
А если кто-то будет наезжать здесь, скажите, что Вы человек Макса))     
Тогда уж лучше "от Макса" Смеющийся

У входа в гостиницу:
- Эй, мужики, вы куда?! Вам сюда нельзя.
- Мы от Саныча.
- Какого такого Саныча?
- Ты чё, Саныча не знаешь?
- Нет... Проходите.
Записан
alexis031182
Гость
« Ответ #63 : Июнь 08, 2012, 21:01 »

)) пока никто особо не наезжал, хотя вначале ожидала много критики
Самим бы разобраться прежде чем начинать критиковать Улыбающийся
Записан
alexis031182
Гость
« Ответ #64 : Июнь 08, 2012, 21:12 »

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

И пошел поток бреда:
Дмитрий, чем больше Вы хамите, тем яснее всем что своих мыслей у Вас нет, а попытки скрыть это кучей прочитанного (но никак не осмысленного) выглядят убого. Впредь отвечать Вам просто не буду, нет смысла тратить время на хамло
Умение корректно "задавить" оппонента в споре уважается несколько больше. На иные методы - другие реверансы. Да просто как-то ни к чему такое...
Записан
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #65 : Июнь 08, 2012, 21:26 »

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

Честно говоря, пришлось задуматься над Вашими словами по поводу нерациональности наследования от того же QPushButton. Спустя время, дошло, что можно вместо наследования применить обратный метод - декорирование. То есть, обслуживаемый класс помещаем в некий класс Декоратор, в котором и будет содержаться указатель на медиатор и указатель на обслуживаемый объект. Думаю, это должно помочь решить возникшую проблему.
Я не вижу зачем нужен этот указатель. Если "с контролом что-то случилось" - везде родитель получит управление (через сигналы или как - детали). Также не вижу ничего против обработки (содержательных действий) в окне-родителе. Оно ведь все контролы и создавало, ну ему и карты в руки
Записан
alexis031182
Гость
« Ответ #66 : Июнь 08, 2012, 21:48 »

Я не вижу зачем нужен этот указатель. Если "с контролом что-то случилось" - везде родитель получит управление (через сигналы или как - детали). Также не вижу ничего против обработки (содержательных действий) в окне-родителе. Оно ведь все контролы и создавало, ну ему и карты в руки
Да нет, Ваше решение отличное, применительно к обсуждаемому нами маленькому примеру. Но я всё размышляю в сторону своего проекта вебсервера. Когда я к epoll-событиям подключил сигнал-слоты и QEvent, программа стала работать значительно медленнее. Пробовал по всякому извращаться, но скорости не прибавилось. Поэтому я задумался о решении, которое на уровне затрат обычного вызова функции позволит столь же гибко управлять всеми процессами взаимосвязанных объектов, как это сделано в случае событийной модели Qt.
Записан
m_ax
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 2095



Просмотр профиля
« Ответ #67 : Июнь 08, 2012, 22:21 »

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

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

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

Над водой луна двурога. Сяду выпью за Ван Гога. Хорошо, что кот не пьет, Он и так меня поймет..

Arch Linux Plasma 5
m_ax
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 2095



Просмотр профиля
« Ответ #68 : Июнь 08, 2012, 22:39 »

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

Над водой луна двурога. Сяду выпью за Ван Гога. Хорошо, что кот не пьет, Он и так меня поймет..

Arch Linux Plasma 5
Igors
Джедай : наставник для всех
*******
Offline Offline

Сообщений: 11445


Просмотр профиля
« Ответ #69 : Июнь 09, 2012, 01:20 »

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

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

Для того наверно чтобы все время не создавать объект QSettings для каждого окна, а чтобы делать это централизовано. В менеджере настроек сразу определяется куда будут записываться настройки, а также происходит инициализация объекта QSettings:
m_settings(qApp->organizationName(), qApp->applicationName())
Кроме того мы сможем менять поведение менеджера на специфичесое для данного проекта.
Хмм... ну может и так, не исключено. Однако такой подход предвзятен, мы как бы "подгоняем задачу под паттерн" - а должно быть наоборот. 
Записан
Страниц: 1 ... 3 4 [5]   Вверх
  Печать  
 
Перейти в:  


Страница сгенерирована за 0.079 секунд. Запросов: 22.