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

[Igors]

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

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

[nata267]

это не мой код, а тех кто писал дизайнер. наверно я не сумела донести идею(((

Просто он порезан в листингах. Часть описания взаимодействия Вы привели словами, часть в коде. Да и много его, чтобы, извините, с кондачка въехать.

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

[nata267]

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

Это неправильное понимание. Не только окна. Любые компоненты системы. Настройки, всякие менеджеры плагинов, дополнений и т.д. Все модули системы, которые в дальнейшем будут взаимодействовать. Например окну потребуется прочитать настройки через менеджера настроек.  Или при редактировании данных в окне сообщить менеджеру свойств, что свойства редактируемого объекта изменились. Окно должно взаимодействовать как минимум с двумя компонентами - Менеджер настроек, Менеджер свойств объектов. Если бы они взаимодействовали напрямую то это было бы 2 связи. А так одна. Только с медиатором.

[alexis031182]

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

++

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

[nata267]

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

++

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

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

[alexis031182]

Хм... ещё раз пересмотрел код. Там получается Вы просто медиатор используете как хранилище указателей на взаимодействующие объекты. Медиатор в общем-то ничего сам и не делает. Это реализация не медиатора. Медиатор, наоборот, сам должен вызывать соответствующие методы объекта-ответчика, исходя из запроса объекта-исходника. Я не ошибаюсь?

[nata267]

в следующий раз нарисую uml-диаграммы классов

[nata267]

Хм... ещё раз пересмотрел код. Там получается Вы просто медиатор используете как хранилище указателей на взаимодействующие объекты. Медиатор в общем-то ничего сам и не делает. Это реализация не медиатора. Медиатор, наоборот, сам должен вызывать соответствующие методы объекта-ответчика, исходя из запроса объекта-исходника. Я не ошибаюсь?

Согласна. Вот это я и пытаюсь понять.  Я говорю, что я новичок в этом вопросе. И ещё у меня вопрос. Почему указатели хранятся в классе MediatorInterfacePrivate? Зачем это надо??

[nata267]

Хм... ещё раз пересмотрел код. Там получается Вы просто медиатор используете как хранилище указателей на взаимодействующие объекты. Медиатор в общем-то ничего сам и не делает. Это реализация не медиатора. Медиатор, наоборот, сам должен вызывать соответствующие методы объекта-ответчика, исходя из запроса объекта-исходника. Я не ошибаюсь?

И кстати очень удобное хранилище, теперь придется исправить все мои листинги и написать вместо медиатор - хранилище указателей или как-то так) Вы меня простите если я этого не буду делать. Буду путать народ неправильными терминами))

[alexis031182]

Согласна. Вот это я и пытаюсь понять.  Я говорю, что я новичок в этом вопросе. И ещё у меня вопрос. Почему указатели хранятся в классе MediatorInterfacePrivate? Зачем это надо??

А это обеспечивается совместный доступ к данным класса. Здесь хорошо описано это дело

[alexis031182]

И кстати очень удобное хранилище, теперь придется исправить все мои листинги и написать вместо медиатор - хранилище указателей или как-то так) Вы меня простите если я этого не буду делать. Буду путать народ неправильными терминами))

Вот и разобрались, значит. Как обычно в случае с патернами получилось не то, что подразумевалось делать Медиатор - это набор действий над объектами вкупе с хранилищем указателей на эти объекты. Тогда Ваш назвать можно, например, PointerContainer

[Igors]

Это неправильное понимание.

Вот это и есть отрицательная сторона паттернов - переоценка прочитанного. Вы уже (якобы) знаете что правильно  

Не только окна. Любые компоненты системы. Настройки, всякие менеджеры плагинов, дополнений и т.д. Все модули системы, которые в дальнейшем будут взаимодействовать. Например окну потребуется прочитать настройки через менеджера настроек.  Или при редактировании данных в окне сообщить менеджеру свойств, что свойства редактируемого объекта изменились. Окно должно взаимодействовать как минимум с двумя компонентами - Менеджер настроек, Менеджер свойств объектов. Если бы они взаимодействовали напрямую то это было бы 2 связи. А так одна. Только с медиатором.

Ну минусы прямого взаимодействия очевидны, прокладочки/переходнички ставить приходится. Однако совсем непросто оценить будет ли это в плюс или в минус. Чем полезен промежуточный класс? Какой полезный ф-ционал он несет? У Вас я не увидел никакого. Зачем окну нужен "Менеджер настроек"? Чем плохо если окно  просто запишет прочитает QSettings? Если мне нужно сообщить "данные изменились" - почему просто не эмиттить сигнал? и.т.д. И не надо думать что если это писали норвежские программисты - то это уж немеряный вышак. Там лохов тоже хватает  

[nata267]

Согласна. Вот это я и пытаюсь понять.  Я говорю, что я новичок в этом вопросе. И ещё у меня вопрос. Почему указатели хранятся в классе MediatorInterfacePrivate? Зачем это надо??

А это обеспечивается совместный доступ к данным класса. Здесь хорошо описано это дело

а зачем конструктор копирования и операция присваивания перенесены в секцию private? Ведь если я не ошибаюсь это запрещает копирование и присваивания, и гарантирует что копии не будет, а ведь в приведенной статьи весь смысл в них??  Я наверно чегото не догоняю

[nata267]

Это неправильное понимание.

Вот это и есть отрицательная сторона паттернов - переоценка прочитанного. Вы уже (якобы) знаете что правильно  

Не только окна. Любые компоненты системы. Настройки, всякие менеджеры плагинов, дополнений и т.д. Все модули системы, которые в дальнейшем будут взаимодействовать. Например окну потребуется прочитать настройки через менеджера настроек.  Или при редактировании данных в окне сообщить менеджеру свойств, что свойства редактируемого объекта изменились. Окно должно взаимодействовать как минимум с двумя компонентами - Менеджер настроек, Менеджер свойств объектов. Если бы они взаимодействовали напрямую то это было бы 2 связи. А так одна. Только с медиатором.

Ну минусы прямого взаимодействия очевидны, прокладочки/переходнички ставить приходится. Однако совсем непросто оценить будет ли это в плюс или в минус. Чем полезен промежуточный класс? Какой полезный ф-ционал он несет? У Вас я не увидел никакого. Зачем окну нужен "Менеджер настроек"? Чем плохо если окно  просто запишет прочитает QSettings? Если мне нужно сообщить "данные изменились" - почему просто не эмиттить сигнал? и.т.д. И не надо думать что если это писали норвежские программисты - то это уж немеряный вышак. Там лохов тоже хватает  

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

[alexis031182]

а зачем конструктор копирования и операция присваивания перенесены в секцию private? Ведь если я не ошибаюсь это запрещает копирование и присваивания, а ведь в приведенной статьи весь смысл в них?? Я наверно чегото не догоняю

Как зачем? Вы же создаёте по сути э-э-э... локальный синглтон, который содержит умные указатели на взаимодействующие объекты. К чему операции копирования и присваивания самого медиатора?