Russian Qt Forum

Qt => Кладовая готовых решений => Тема начата: nata267 от Июнь 07, 2012, 15:00



Название: Вопрос по архитектуре приложения. Медиатор
Отправлено: nata267 от Июнь 07, 2012, 15:00
Взято из QtDesigner.

Как в приложении реализовать доступ к любому компоненту системы из любого компонента системы, не
связывая компоненты напрямую друг с другом. Реализуется с помощью паттерна "Медиатор". Вот нашла реализацию в одном проекте.

Интерфейс медиатора. Операторы копирования и присваивания медиатора в секции private
Код:
class MediatorInterface : public QObject
{
    Q_OBJECT

public:

    MediatorInterface(QObject *parent = 0);
    virtual ~MediatorInterface();

    
    ComponentOneInterface *componentOne() const;
    ComponentTwoInterface *componentTwo() const;
    ComponentThreeInterface *componentThree() const;


    void setComponentOne(ComponentOneInterface *componentOne);
    void setComponentTwo(ComponentTwoInterface *componentTwo);
    
protected:
    void setComponentThree(ComponentThreeInterface *componentThree);

private:
    MediatorInterfacePrivate *d;

private:
    MediatorInterface(const MediatorInterface &other);
    void operator = (const MediatorInterface &other);
};

//конструктор
MediatorInterface::MediatorInterface(QObject *parent)
    : QObject(parent),
      d(new MediatorInterfacePrivate())
{
}

//деструктор
MediatorInterface::~MediatorInterface()
{
    delete d;
}

//возвращает интерфейс компонента
ComponentOneInterface *MediatorInterface::componentOne() const
{
    return d->m_componentOne;
}

//устанавливает компонент
void MediatorInterface::setComponentOne(ComponentOneInterface *componentOne)
{
    d->m_componentOne = componentOne;
}

Инкапсуляция указателей (не знаю можно ли так выразится). Или это опять какой-то шаблон???
Код:
class MediatorInterfacePrivate {

public:
    MediatorInterfacePrivate();
    ~MediatorInterfacePrivate();


    QPointer<ComponentOneInterface> m_componentOne;
    QPointer<ComponentTwoInterface> m_componentTwo;
    QPointer<ComponentThreeInterface> m_componentThree;
    
};

//конструктор
MediatorInterfacePrivate::MediatorInterfacePrivate() :
    m_componentOne(0),
    m_componentTwo(0),
    m_componentThree(0)
{
}

//деструктор
MediatorInterfacePrivate::~MediatorInterfacePrivate()
{
    delete m_componentOne;
    delete m_componentTwo;
    delete m_componentThree;
}


Конккретный медиатор проекта
Код:
class Mediator : public MediatorInterface
{
    Q_OBJECT

public:
    Mediator(QObject *parent = 0);
    virtual ~Mediator();
};


Mediator::Mediator(QObject *parent)
    : MediatorInterface(parent)
{

    ComponentThree *componentThree = new ComponentThree(this);
    setComponentThree(componentThree);
    ............
    создание компонентов чья функция set находится в секции protected
}

Указатель на медиатора передается в конструктор компонента.

Код:
class ComponentOne: public ComponentOneInterface
{
    Q_OBJECT

public:
    ComponentOne(MediatorInterface *core, QObject *parent = 0);
    virtual ~ComponentOne();

    .....
}


Название: Re: Вопрос по архитектуре приложения
Отправлено: Igors от Июнь 07, 2012, 17:13
Как в приложении реализовать доступ к любому компоненту системы из любого компонента системы, не
связывая компоненты напрямую друг с другом. Реализуется с помощью паттерна "Медиатор". Вот нашла реализацию в одном проекте.
Ну так в чем вопрос-то? Да, я узнал что есть паттерн "медиатор" который что-то делает. Если Вы считаете что нужно его использовать в Вашей задаче - ну Вам виднее. Но темы для обсуждения не видно  :)

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


Название: Re: Вопрос по архитектуре приложения
Отправлено: alexis031182 от Июнь 07, 2012, 17:26
Хорошая тема. Насколько я помню, медиатор нужен для обеспечения двунаправленной связи между объектами. В варианте с наследованием приходится сохранять ссылки друг на друга. Медиатор должен работать по принципу "один ко многим". Связанные объекты ничего не знают друг о друге, в то время как медиатор знает обо всех.


Название: Re: Вопрос по архитектуре приложения
Отправлено: nata267 от Июнь 07, 2012, 17:56
Пример из жизни сделал бы обсуждение более продуктивным, пока дубль-пусто  :)

Этот пример как раз взят из реального проекта, а именно редактора форм QDesigner. Я переименовала классы для наглядности. В проекте QDesigner компонентами системы выступают:  QExtensionManager(менеджер дополнений), QDesignerPropertyEditorInterface(интерфейс окна редактора свойств объектов), QDesignerObjectInspectorInterface(интерфейс инспектора объектов), QDesignerActionEditorInterface(интерфейс окна редактора Аctions), а также QDesignerPluginManager, QtResourceModel, QDesignerSettingsInterface и многие другие компоненты системы
Моему классу MediatorInterface соответствует класс QDesignerFormEditorInterface.


Название: Re: Вопрос по архитектуре приложения
Отправлено: nata267 от Июнь 07, 2012, 18:23
Приведу пример как в методах компонентов используется указатель на медиатора. Компонентом выступает ActionEditor - окно редактора Actions

Код:
class ActionEditor: public QDesignerActionEditorInterface
{
    Q_OBJECT
public:
    explicit ActionEditor(QDesignerFormEditorInterface *core, QWidget *parent = 0, Qt::WindowFlags flags = 0);
    virtual ~ActionEditor();
....

интерфейс которого:

Код:
class QDesignerActionEditorInterface: public QWidget
{
    Q_OBJECT
public:
    QDesignerActionEditorInterface(QWidget *parent, Qt::WindowFlags flags = 0);
    virtual ~QDesignerActionEditorInterface();

    virtual QDesignerFormEditorInterface *core() const;
...........
};


QDesignerFormEditorInterface *core - указатель на медиатора

вот отрывки из методов  ActionEditor в которых используется указатель на медиатора. В первом методе мы обращаемся к компоненту настроек, для восстановления настроек окна, во втором обращаемся к компоненту QDesignerPropertySheetExtension. Это компонент дополнения связаного как-то со свойствами объектов, может быть с их хранением и чтением, пока ещё не разобралась:

Код:
void ActionEditor::restoreSettings()
{
    QDesignerSettingsInterface *settings = m_core->settingsManager();
    m_actionView->setViewMode(settings->value(QLatin1String(actionEditorViewModeKey), 0).toInt());
    updateViewModeActions();
}
...
void ActionEditor::manageAction(QAction *action)
{
    .....
    core()->metaDataBase()->add(action);

   .......

    QDesignerPropertySheetExtension *sheet = qt_extension<QDesignerPropertySheetExtension*>(core()->extensionManager(), action);
    sheet->setChanged(sheet->indexOf(QLatin1String(objectNamePropertyC)), true);
    sheet->setChanged(sheet->indexOf(QLatin1String(textPropertyC)), true);
    refreshIconPropertyChanged(action, sheet);

   ...............
}


Название: Re: Вопрос по архитектуре приложения
Отправлено: alexis031182 от Июнь 07, 2012, 18:29
Оно конечно хорошо, но если речь о концепции, то лучше, наверное, пример взять поближе к простым смертным, на вроде меня. Обосновано ли использование медиатора в случае, если требуется взаимодействие, например, объектов файлов и объектов групп владельцев этих файлов между собой? Естественно, что один файл может быть доступен нескольким группам владельцев. Или достаточно наследования? Но как в таком случае быть, если потребуется изменить поведение программы из-за смены логики взаимодействия файлов с некоторыми группами владельцев?


Название: Re: Вопрос по архитектуре приложения
Отправлено: nata267 от Июнь 07, 2012, 19:02
Оно конечно хорошо, но если речь о концепции, то лучше, наверное, пример взять поближе к простым смертным, на вроде меня. Обосновано ли использование медиатора в случае, если требуется взаимодействие, например, объектов файлов и объектов групп владельцев этих файлов между собой? Естественно, что один файл может быть доступен нескольким группам владельцев. Или достаточно наследования? Но как в таком случае быть, если потребуется изменить поведение программы из-за смены логики взаимодействия файлов с некоторыми группами владельцев?

Возможно и не обосновано, зависит от задачи. Приведите ваш пример. Просто я проектировала интерфейс графического редактора и у меня стояла такая задача. Я использовала singleton для предоставления глобальной точки доступа к компонентам. Вот не пойму какое решение лучше и в чем преимущества этих методов.


Название: Re: Вопрос по архитектуре приложения
Отправлено: Igors от Июнь 07, 2012, 19:05
Оно конечно хорошо, но если речь о концепции, то лучше, наверное, пример взять поближе к простым смертным, на вроде меня.
Именно так. Во-первых затруднительно вникнуть во все классы дизайнера. Лично я совсем не понял какова цель. Во-вторых, пример основывается на исходных классах с мощной ф-циональностью, в этом случае может проходить все что угодно - но это ни о чем не говорит. Более простой, житейский пример был бы более уместен


Название: Re: Вопрос по архитектуре приложения
Отправлено: nata267 от Июнь 07, 2012, 19:15
Оно конечно хорошо, но если речь о концепции, то лучше, наверное, пример взять поближе к простым смертным, на вроде меня.
Именно так. Во-первых затруднительно вникнуть во все классы дизайнера. Лично я совсем не понял какова цель. Во-вторых, пример основывается на исходных классах с мощной ф-циональностью, в этом случае может проходить все что угодно - но это ни о чем не говорит. Более простой, житейский пример был бы более уместен

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


Название: Re: Вопрос по архитектуре приложения
Отправлено: alexis031182 от Июнь 07, 2012, 19:25
Возможно и не обосновано, зависит от задачи. Приведите ваш пример.
Я пример задачи и привёл, просто образно, без кода. Мне лично самому проще так воспринимать. Спросил мнение тех, кто сильно в теме.

Просто я проектировала интерфейс графического редактора и у меня стояла такая задача. Я использовала singleton для предоставления глобальной точки доступа к компонентам. Вот не пойму какое решение лучше и в чем преимущества этих методов.
По моему мнению, медиатор в отличие от синглтона более специфичен. Он предназначен для работы с конкретными объектами. Если для целей, аналогичных Вашим, использовать синглтон, то тот довольно быстро превратится в указателе-помойку. Ну разве что тогда создавать кучу специфичных синглтонов, но это мне кажется тоже не выход. Вообще, чем меньше глобального доступа, тем лучше.

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


Название: Re: Вопрос по архитектуре приложения
Отправлено: nata267 от Июнь 07, 2012, 19:26
Я вообще-то новичок в паттернах, хотелось бы их обсудить, так как при приеме на работу обычно требуют их знание и умение их применять. Вот хотелось бы вписываться в данный формат. Думаю опытные программисты здесь являются гуру паттернов. Лично меня при приеме на работу ими пытали неоднократно.


Название: Re: Вопрос по архитектуре приложения
Отправлено: nata267 от Июнь 07, 2012, 19:33
Возможно и не обосновано, зависит от задачи. Приведите ваш пример.
Я пример задачи и привёл, просто образно, без кода. Мне лично самому проще так воспринимать. Спросил мнение тех, кто сильно в теме.

Просто я проектировала интерфейс графического редактора и у меня стояла такая задача. Я использовала singleton для предоставления глобальной точки доступа к компонентам. Вот не пойму какое решение лучше и в чем преимущества этих методов.
По моему мнению, медиатор в отличие от синглтона более специфичен. Он предназначен для работы с конкретными объектами. Если для целей, аналогичных Вашим, использовать синглтон, то тот довольно быстро превратится в указателе-помойку. Ну разве что тогда создавать кучу специфичных синглтонов, но это мне кажется тоже не выход. Вообще, чем меньше глобального доступа, тем лучше.

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

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


Название: Re: Вопрос по архитектуре приложения
Отправлено: alexis031182 от Июнь 07, 2012, 19:40
Да мне тоже понравилось решение. Но что код очень сложен для понимания - это минус. Классы разнесены по разным файлам. Пока соберешь картину целиком, голову сломаешь.
А всё потому, что патерны в чистом виде наверное и не применяются. Обязательно хоть какая-то отсебятина будет. А без неё никак, поскольку непременно в каждом случае существует специфика задачи. Да даже просто нет стандарта в именовании классов. Я вот и имею представление о медиаторе, но Ваш код понять не сумел :)


Название: Re: Вопрос по архитектуре приложения
Отправлено: nata267 от Июнь 07, 2012, 19:45
Да мне тоже понравилось решение. Но что код очень сложен для понимания - это минус. Классы разнесены по разным файлам. Пока соберешь картину целиком, голову сломаешь.
А всё потому, что патерны в чистом виде наверное и не применяются. Обязательно хоть какая-то отсебятина будет. А без неё никак, поскольку непременно в каждом случае существует специфика задачи. Да даже просто нет стандарта в именовании классов. Я вот и имею представление о медиаторе, но Ваш код понять не сумел :)

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


Название: Re: Вопрос по архитектуре приложения
Отправлено: alexis031182 от Июнь 07, 2012, 19:50
это не мой код, а тех кто писал дизайнер. наверно я не сумела донести идею(((
Просто он порезан в листингах. Часть описания взаимодействия Вы привели словами, часть в коде. Да и много его, чтобы, извините, с кондачка въехать.


Название: Re: Вопрос по архитектуре приложения
Отправлено: Igors от Июнь 07, 2012, 19:55
Никаким гуру паттернов я не являюсь, скорее наоборот  :)  Вероятно (да почти наверняка) я их постоянно применяю, но никогда не задумывался о том "а какой же это паттерн", как он называется и.т.п.

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


Название: Re: Вопрос по архитектуре приложения
Отправлено: nata267 от Июнь 07, 2012, 19:59
это не мой код, а тех кто писал дизайнер. наверно я не сумела донести идею(((
Просто он порезан в листингах. Часть описания взаимодействия Вы привели словами, часть в коде. Да и много его, чтобы, извините, с кондачка въехать.

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


Название: Re: Вопрос по архитектуре приложения
Отправлено: nata267 от Июнь 07, 2012, 20:02

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


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





Название: Re: Вопрос по архитектуре приложения
Отправлено: alexis031182 от Июнь 07, 2012, 20:05
Никаким гуру паттернов я не являюсь, скорее наоборот  :)  Вероятно (да почти наверняка) я их постоянно применяю, но никогда не задумывался о том "а какой же это паттерн", как он называется и.т.п.
++

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


Название: Re: Вопрос по архитектуре приложения
Отправлено: nata267 от Июнь 07, 2012, 20:10
Никаким гуру паттернов я не являюсь, скорее наоборот  :)  Вероятно (да почти наверняка) я их постоянно применяю, но никогда не задумывался о том "а какой же это паттерн", как он называется и.т.п.
++

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

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


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


Название: Re: Вопрос по архитектуре приложения
Отправлено: nata267 от Июнь 07, 2012, 20:26
в следующий раз нарисую uml-диаграммы классов


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

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


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

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


Название: Re: Вопрос по архитектуре приложения
Отправлено: alexis031182 от Июнь 07, 2012, 20:42
Согласна. Вот это я и пытаюсь понять.  Я говорю, что я новичок в этом вопросе. И ещё у меня вопрос. Почему указатели хранятся в классе MediatorInterfacePrivate? Зачем это надо??
А это обеспечивается совместный доступ к данным класса. Здесь (http://qt.osdn.org.ua/data-sharing.html) хорошо описано это дело


Название: Re: Вопрос по архитектуре приложения
Отправлено: alexis031182 от Июнь 07, 2012, 20:46
И кстати очень удобное хранилище, теперь придется исправить все мои листинги и написать вместо медиатор - хранилище указателей или как-то так) Вы меня простите если я этого не буду делать. Буду путать народ неправильными терминами))
Вот и разобрались, значит. Как обычно в случае с патернами получилось не то, что подразумевалось делать :) Медиатор - это набор действий над объектами вкупе с хранилищем указателей на эти объекты. Тогда Ваш назвать можно, например, PointerContainer :)


Название: Re: Вопрос по архитектуре приложения
Отправлено: Igors от Июнь 07, 2012, 20:48
Это неправильное понимание.
Вот это и есть отрицательная сторона паттернов - переоценка прочитанного. Вы уже (якобы) знаете что правильно  :)

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


Название: Re: Вопрос по архитектуре приложения
Отправлено: nata267 от Июнь 07, 2012, 20:55
Согласна. Вот это я и пытаюсь понять.  Я говорю, что я новичок в этом вопросе. И ещё у меня вопрос. Почему указатели хранятся в классе MediatorInterfacePrivate? Зачем это надо??
А это обеспечивается совместный доступ к данным класса. Здесь (http://qt.osdn.org.ua/data-sharing.html) хорошо описано это дело

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


Название: Re: Вопрос по архитектуре приложения
Отправлено: nata267 от Июнь 07, 2012, 20:58
Это неправильное понимание.
Вот это и есть отрицательная сторона паттернов - переоценка прочитанного. Вы уже (якобы) знаете что правильно  :)

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

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


Название: Re: Вопрос по архитектуре приложения
Отправлено: alexis031182 от Июнь 07, 2012, 20:59
а зачем конструктор копирования и операция присваивания перенесены в секцию private? Ведь если я не ошибаюсь это запрещает копирование и присваивания, а ведь в приведенной статьи весь смысл в них?? Я наверно чегото не догоняю
Как зачем? Вы же создаёте по сути э-э-э... локальный синглтон, который содержит умные указатели на взаимодействующие объекты. К чему операции копирования и присваивания самого медиатора?


Название: Re: Вопрос по архитектуре приложения
Отправлено: nata267 от Июнь 07, 2012, 21:04
а зачем конструктор копирования и операция присваивания перенесены в секцию private? Ведь если я не ошибаюсь это запрещает копирование и присваивания, а ведь в приведенной статьи весь смысл в них?? Я наверно чегото не догоняю
Как зачем? Вы же создаёте по сути э-э-э... локальный синглтон, который содержит умные указатели на взаимодействующие объекты. К чему операции копирования и присваивания самого медиатора?

спасибо за ссылку, подробно изучу данный метод


Название: Re: Вопрос по архитектуре приложения
Отправлено: Igors от Июнь 07, 2012, 21:27
А это обеспечивается совместный доступ к данным класса. Здесь (http://qt.osdn.org.ua/data-sharing.html) хорошо описано это дело
Как зачем? Вы же создаёте по сути э-э-э... локальный синглтон, который содержит умные указатели на взаимодействующие объекты. К чему операции копирования и присваивания самого медиатора?
Ну как сказать... Это конечно "хорошие вещи". Но вызываются ли они необходимостью? Кто-то собирался копировать медиатор? Нет, так зачем тогда его шарить? Зачем забивать голову информацией которая, вообще говоря, полезна, но никак не помогает решить задачу? Со временем таких, по сути бесполезных, знаний становится больше и больше, и уже все труднее найти действительно нужную вещь на своем чердаке (как-то так говорил Холмс  :))


Название: Re: Вопрос по архитектуре приложения
Отправлено: alexis031182 от Июнь 07, 2012, 22:08
Ну как сказать... Это конечно "хорошие вещи".
Что в них плохого?

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

Зачем забивать голову информацией которая, вообще говоря, полезна, но никак не помогает решить задачу? Со временем таких, по сути бесполезных, знаний становится больше и больше, и уже все труднее найти действительно нужную вещь на своем чердаке (как-то так говорил Холмс  :))
Согласен, но у каждого свой потенциал, да и всё чаще бытует половинчатое заполнение чердака, нежели его переполнение.


Название: Re: Вопрос по архитектуре приложения
Отправлено: DmitryM от Июнь 08, 2012, 07:06
Медиатор пытается решиться следующую проблему:
Цитировать
Обеспечить взаимодействие множества обьектов, сформировав при этом слабую связанность и избавив объекты от необходимости явно ссылаться друг на друга.
Решить такую задачу можно сигнал-слотами.


Название: Re: Вопрос по архитектуре приложения
Отправлено: Akon от Июнь 08, 2012, 07:56
Медиатор на пальцах: пусть есть окно с тремя кнопками, нажав на одну, остальные тоже должны нажаться. Теперь забудем о сигналах и слотах. Решение в лоб - каждая кнопка должна знать о других, чтобы вызывать их метод press(), но вместо этого каждой кнопке подсовывается медиатор, кнопка использует медиатор для уведомления о нажатии, медиатор выполняет нажатия оставшихся кнопок.

DmitryM +1
Медиаторы являются неотъемлеными компонентами в фреймфорках с юникастовыми сигналами (например, VCL (Delphi, C++Builder)). С мультикастовыми сигналами необходимость использовать медиатор возникает реже.

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


Название: Re: Вопрос по архитектуре приложения
Отправлено: Krysk от Июнь 08, 2012, 09:27
Медиатор почти тоже самое что контекст. Только в контексте не используются лишние методы взаимодействия со связанными объектами он лишь содержит ссылки на объекты ну и может быть всякие там обсерверы на случай подмены. Удобен тем, что не нужно производить подмену в каждом конкретном объекте, достаточно поменять в контексте.

Сигналы слоты это не то... подмена их не такая простая задача (про синхронизацию вообще молчу), так как требуется отсоединиться от прошлого объекта и присоединиться к текущему и чем сложнее контракт тем больше выноса мозгов. А так сделал view*.setContext или context.set("selectionManager", newSelectionManager)


Название: Re: Вопрос по архитектуре приложения
Отправлено: DmitryM от Июнь 08, 2012, 10:04
Самое очевидное назначение медиатора это ООП альтернатива сallback! В этой роли мне больше нравятся вложенные классы Java и делегаты в C#.
Думаю, что в чистом виде он вряд ли нужен.

Медиатор почти тоже самое что контекст.
Это про паттерн State?


Название: Re: Вопрос по архитектуре приложения
Отправлено: Igors от Июнь 08, 2012, 12:03
Медиатор на пальцах: пусть есть окно с тремя кнопками, нажав на одну, остальные тоже должны нажаться. Теперь забудем о сигналах и слотах. Решение в лоб - каждая кнопка должна знать о других, чтобы вызывать их метод press(), но вместо этого каждой кнопке подсовывается медиатор, кнопка использует медиатор для уведомления о нажатии, медиатор выполняет нажатия оставшихся кнопок.
Хороший пример с кнопками. Однако разговор стал "слишком общим" :) Давайте попробуем написать такой медиатор, пусть в псевдокоде. Я лично что-то затрудняюсь "сходу"

Только в простых случаях сигнал связывается непосредственно с press, в чуть более сложных - все равно с передаточным/промежуточным классом.


Название: Re: Вопрос по архитектуре приложения
Отправлено: DmitryM от Июнь 08, 2012, 12:41
Давайте попробуем написать такой медиатор, пусть в псевдокоде. Я лично что-то затрудняюсь "сходу"
Вот тебе example (http://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D1%81%D1%80%D0%B5%D0%B4%D0%BD%D0%B8%D0%BA_(%D1%88%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F)) на разных ЯП включая C++.


Название: Re: Вопрос по архитектуре приложения
Отправлено: Igors от Июнь 08, 2012, 12:53
Вот тебе example (http://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D1%81%D1%80%D0%B5%D0%B4%D0%BD%D0%B8%D0%BA_(%D1%88%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F)) на разных ЯП включая C++.
Ваша эрудиция впечатляет, я бы никогда не нашел этой ссылки. И как Вы оцениваете то что там написано?


Название: Re: Вопрос по архитектуре приложения
Отправлено: alexis031182 от Июнь 08, 2012, 13:19
Вот тебе example на разных ЯП включая C++.
:(


Название: Re: Вопрос по архитектуре приложения
Отправлено: alexis031182 от Июнь 08, 2012, 13:25
Может быть начнём с совсем простого? Гуру могут нервно покурить в сторонке, а мы пока так, сами в песочнице покопаемся.
Код:
class Mediator;

class Button
{
public:
   Button(Mediator *mediator) {_mediator = mediator;}

   void click() {_mediator->buttonClicked(this);}

   void autoClick() {}

private:
   Mediator _mediator;

};


class Mediator
{
public:
   Mediator() {}

   void addButton(Button *button) {_buttons.append(button);}

   void buttonClicked(Button *button) {
      for(int i = 0, n = buttons.size(); i < n; ++i) {
         if(button == buttons.at(i)) continue;
         buttons.at(i)->autoClick();
      }
   }

private:
   List<Button*> _buttons;

};
Пример с задачей наверное всё-таки не самый удачный, т.к. подразумевает рекурсию. Если все кнопки подключены к одному и тому же событию, плюс зациклены, то и получим в итоге круговорот. В коде пришлось ввести отдельную функцию autoClick(), чтобы избежать этой неприятности.

Как видно, медиатор при решении данной задачи не очень-то эффективен. Проще на сигналах, да или в лоб, как описывалось выше, через ссылки. Нужен другой пример.


Название: Re: Вопрос по архитектуре приложения
Отправлено: Igors от Июнь 08, 2012, 13:38
Как видно, медиатор при решении данной задачи не очень-то эффективен.
Вот то-то и оно. Этот эффект очень типичен. С первого взгляда - ну вот же, тот самый случай, точно этот паттерн. Однако после того как маленько вник, попробовал - да ни фига, это или совсем другой или вообще "по мотивам".

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


Название: Re: Вопрос по архитектуре приложения
Отправлено: alexis031182 от Июнь 08, 2012, 13:46
Если, допустим, изменить задачу таким образом. Пусть существует некоторое кол-во кнопок (Button) и надписей (Label). Нужно при помощи медиатора реализовать логику: если нажали на любую из кнопок, то сменить текст в надписях. Если нажали на надпись, то сменить текст на кнопках. Один из вариантов реализации может быть таким:
Код:
class Mediator;

class Widget
{
public:
   Widget(Mediator *mediator, const String &caption)
      {_mediator = mediator; _caption = caption;}

   virtual Mediator::WidgetType type() const = 0;

   void click() {_mediator->widgetClicked(this);}

   void setCaption(const String &new_caption) {_caption = new_caption;}

private:
   Mediator *_mediator;

   String _caption;

};


class Button : public Widget
{
public:
   Button(const String &caption, Mediator *mediator) : Widget(mediator, caption) {}

   Mediator::WidgetType type() const {return Mediator::WT_BUTTON;}

};


class Label : public Widget
{
public:
   Label(const String &caption, Mediator *mediator) : Widget(mediator, caption) {}

   Mediator::WidgetType type() const {return Mediator::WT_LABEL;}

};


class Mediator
{
public:
   enum WidgetType {WT_BUTTON, WT_LABEL};

   Mediator() {}

   void addWidget(Widget *widget)
      {_widgets.insertMulti(widget->type(), widget);}

   void widgetClicked(Widget *widget) {
      QList<Widget*> widgets;

      String new_caption;

      switch(widget->type()) {
         case Mediator::WT_BUTTON: {
            widgets = _widgets.values(Mediator::WT_LABEL);
            new_caption = "button clicked";
         } break;

         case Mediator::WT_LABEL: {
            widgets = _widgets.values(Mediator::WT_BUTTON);
            new_caption = "label clicked";
         } break;
      }

      for(int i = 0, n = widgets.size(); i < n; ++i) {
         widgets.at(i)->setCaption(new_caption);
      }
   }

private:
   Hash<WidgetType, Widget*> _widgets;

};
Уже наверное лучше. А почему? Логика подсказывает, что использование медиатора становится наиболее обоснованным в тех случаях, когда требуется обслуживать большое кол-во разнородных объектов. В случае с просто одними кнопками, мы имеем неэффективного посредника, тогда как в варианте с разнообразными виджетами, сгруппированными по единому функционалу (здесь, получается, это тоже важный момент), медиатор выглядит уже не столь инвалидно.


Название: Re: Вопрос по архитектуре приложения
Отправлено: alexis031182 от Июнь 08, 2012, 13:49
Вот то-то и оно. Этот эффект очень типичен. С первого взгляда - ну вот же, тот самый случай, точно этот паттерн. Однако после того как маленько вник, попробовал - да ни фига, это или совсем другой или вообще "по мотивам".
Igors.same_opinion++;


Название: Re: Вопрос по архитектуре приложения
Отправлено: DmitryM от Июнь 08, 2012, 13:59
Пример с задачей наверное всё-таки не самый удачный, т.к. подразумевает рекурсию. Если все кнопки подключены к одному и тому же событию, плюс зациклены, то и получим в итоге круговорот. В коде пришлось ввести отдельную функцию autoClick(), чтобы избежать этой неприятности.

Как видно, медиатор при решении данной задачи не очень-то эффективен. Проще на сигналах, да или в лоб, как описывалось выше, через ссылки. Нужен другой пример.
Если click() вызывается в момент нажатия на кнопку,  и autoClick() переименовать в someButtonСlickEvent().
То все кнопки получат сообщения о том, что на какую то из них нажали, и могут обработать эту ситуацию.
И тут уже медиатор вполне пригоден.


Название: Re: Вопрос по архитектуре приложения
Отправлено: alexis031182 от Июнь 08, 2012, 14:14
Имеется ввиду отправка медиатором кастомного события someButtonСlickEvent()? Да, конечно, тогда цикличности не будет.

Но всё равно остаётся открытым вопрос, какие плюшки в примере "Медиатор с кнопками" мы получаем в сравнении с традиционным подходом использования перекрёстных ссылок (не говоря уже о сигналах даже)?


Название: Re: Вопрос по архитектуре приложения
Отправлено: DmitryM от Июнь 08, 2012, 14:39
Но всё равно остаётся открытым вопрос, какие плюшки в примере "Медиатор с кнопками" мы получаем в сравнении с традиционным подходом использования перекрёстных ссылок (не говоря уже о сигналах даже)?
повторюсь медиатр призван решить следующую проблему
Цитировать
Обеспечить взаимодействие множества обьектов, сформировав при этом слабую связанность и избавив объекты от необходимости явно ссылаться друг на друга.
Мы не используем перекрестные ссылки. У нас кнопки ничего не знают друг о друге.
Когда мы вынесем someButtonСlickEvent() в базовый класс Коллеги, то кто угодно унаследованный от это класса будет получать сообщение о изменение состояния кнопки.
И не менее приятное, у нас может быть произвольное количество коллег.


Название: Re: Вопрос по архитектуре приложения
Отправлено: alexis031182 от Июнь 08, 2012, 14:56
Хм... тогда получается использование медиатора в примере с кнопками обосновано. Это как некий задел на будущее с соблюдением принципов ООП.

Предварительное "Итого". Конечно логику примера с кнопками имеет смысл реализовывать на перекрёстных ссылках, если не планируется никакого расширения. Скажем, есть две-три кнопки, а ну и ладно, сойдёт, зажарится как-нибудь. Но если понадобится добавить изыска (ещё пару тройку других типов виджетов), то медиатор безусловно пригодится. Вывод верен?


Название: Re: Вопрос по архитектуре приложения
Отправлено: DmitryM от Июнь 08, 2012, 15:13
Но если понадобится добавить изыска (ещё пару тройку других типов виджетов), то медиатор безусловно пригодится. Вывод верен?
Если брать Madiator (GoF) (http://www.ozon.ru/context/detail/id/2457392/), то там пример строится как раз на виджетах.
Не знаю как насчет пары тройки других виджетов, но если пишешь свою библиотеку для работы с виджетами(может пригодиться, если захочешь, что бы было как в FBReader (http://www.fbreader.org/content/linux), поддержка интерфейсов на qt3, qt4, gtk+), то скорее всего пригодиться.


Название: Re: Вопрос по архитектуре приложения
Отправлено: nata267 от Июнь 08, 2012, 16:16
Давайте попробуем написать такой медиатор, пусть в псевдокоде. Я лично что-то затрудняюсь "сходу"
Вот тебе example (http://ru.wikipedia.org/wiki/%D0%9F%D0%BE%D1%81%D1%80%D0%B5%D0%B4%D0%BD%D0%B8%D0%BA_(%D1%88%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F)) на разных ЯП включая C++.


мой пример имеет много общего, за исключением того, что в моем примере медиатор не выполняет сам никаких действий, а просто является посредником, так даже удобнее, но если внести обработку запросов от коллег медиатору в класс медиатора,
Код:
.....
 virtual void Mediator::Send(std::string message, Colleague *colleague)
        {
                if (colleague==static_cast<Colleague*>(m_Colleague1))
                {
                        m_Colleague2->Notify(message);
                }
                else if (colleague==static_cast<Colleague*>(m_Colleague2))
                {
                        m_Colleague1->Notify(message);
                }
        }
....
то получится как раз тот самый медиатор из данной статьи


Название: Re: Вопрос по архитектуре приложения
Отправлено: DmitryM от Июнь 08, 2012, 17:09
с приведением через static_cast главное на запутаться с направлением иерархии наследования :)


Название: Re: Вопрос по архитектуре приложения
Отправлено: alexis031182 от Июнь 08, 2012, 18:15
Сравнение по адресу. Хорошо ли это? Меня терзают не то чтобы смутные, но всё же сомнения, стоит ли это практиковать? Может для классов лучше применять оператор сравнения?


Название: Re: Вопрос по архитектуре приложения
Отправлено: Igors от Июнь 08, 2012, 18:40
Если, допустим, изменить задачу таким образом. Пусть существует некоторое кол-во кнопок (Button) и надписей (Label). Нужно при помощи медиатора реализовать логику: если нажали на любую из кнопок, то сменить текст в надписях.
Лады, поехали

1) Считаю сохранение указателя на медиатор в члене класса Button явно неудачным, т.к. это требует наследования (напр от QPushButton). Эта тема частенько мелькает, поэтому чуть подробнее. Добавляемый ф-ционал слишком мал, и наследник становится "ни пришей ни пристегни". Будете ли Вы использовать такого наследника в др проектах - или хотя бы во всех окнах данного? Если да - вперед, обновляйте все имеющиеся окна (или как-то не тянет? :)) И заодно поразмыслите что если образовался еще другой "наследник-однодневка".  Если нет - ну жить можно, но как-то несолидно. Другой пример: допустим мы затем решили использовать чекбоксы вместо кнопок, или "кнопки с картинками" (др класс) - куда тогда деваться с нашим наследованием?

2) Простое и хорошее решение - отдаться паренту, пусть он меняет тексты. У него всегда все контролы на руках и он знает что делать. Конечно не напрямую В Qt это просто сигнал, в др системах эта точка управления всегда есть (напр WM_COMMAND в WinAPI).

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

Код
C++ (Qt)
class CAdjuster : public QObject {
Q_OBJECT
 
public:
 void AddPair( QWidget *, QWidget * );
 
public slots:
 void Adjust( QWidget * src, TCommand cmd  );
 
typedef enum {
cmd_SetButton,
cmd_SetLabel,
} TCommand;
 
private:
QVector <QPair<QWidget *, QWidget *> > mData;
};
 
Использование:

- делаем экземпляр CAdjuster членом окна
- после создания кнопка+текст вызываем AddPair
- вяжемся сигналами на слот Adjust

Ну а какой это паттерн - я хз. Здесь много знающих людей сорящих ссылками направо и налево, вот они знают  :)


Название: Re: Вопрос по архитектуре приложения
Отправлено: alexis031182 от Июнь 08, 2012, 19:09
Лады, поехали

1) Считаю сохранение указателя на медиатор в члене класса Button явно неудачным, т.к. это требует наследования (напр от QPushButton). Эта тема частенько мелькает, поэтому чуть подробнее. Добавляемый ф-ционал слишком мал, и наследник становится "ни пришей ни пристегни". Будете ли Вы использовать такого наследника в др проектах - или хотя бы во всех окнах данного? Если да - вперед, обновляйте все имеющиеся окна (или как-то не тянет? :)) И заодно поразмыслите что если образовался еще другой "наследник-однодневка".  Если нет - ну жить можно, но как-то несолидно. Другой пример: допустим мы затем решили использовать чекбоксы вместо кнопок, или "кнопки с картинками" (др класс) - куда тогда деваться с нашим наследованием?
Так решение о применении каждого конкретного паттерна должно основываться, исходя из условий задачи. А Вы уже ведёте речь о повсеместном применении. Паттерн медиатора, о котором эта тема, сам по себе не предполагает собственное использование со всеми подряд QPushButton'ами и т.п., но лишь в том случае, когда сгруппированный функционал взаимодействия между объектами классов рационально вынести в посредника. Другими словами, если мы и определили класс-наследник для некоторых QPushButton, то это не значит, что всех подряд надо гнать под одну гребёнку. Я думаю так.


Название: Re: Вопрос по архитектуре приложения
Отправлено: nata267 от Июнь 08, 2012, 19:55
Мне кажется пример с кнопками и метками не совсем жизненный, и в принципе задача довольно простая чтобы с ней заморачиваться. Я предложила данное решение для задачи: Как организовать взаимодействие компонентов сложной системы, не
связывая их напрямую друг с другом. То есть получить систему разбитую на модули но со слабой связностью. Может быть существуют и другие более красивые  решения данной проблемы??


Название: Re: Вопрос по архитектуре приложения
Отправлено: DmitryM от Июнь 08, 2012, 20:17
И пошел поток бреда:
1) ...
2) ...
3) ...
Чукча видно писатель, а не читатель. Вот оригинальный Mediator GoF (http://codelab.ru/pattern/mediator/).
1.
Система оповещения через посредник достаточно большой функционал.
В зависимости от реализации посредника вызов может произойти моментально, отложено или вообще по rpc вызвать кого та на другой машине.  Ты не возмущаешься наличием нескольких евентов у QObject и кучи евентов у QWidget.
2.
Какой парент? Паренты это паттерн Компоновщик(Composite pattern), который служит для организации иерархии объектов(не классов )
3. А ну ка сделай все это на чистом C++


Название: Re: Вопрос по архитектуре приложения
Отправлено: nata267 от Июнь 08, 2012, 20:19
Зачем окну нужен "Менеджер настроек"? Чем плохо если окно  просто запишет прочитает QSettings?
Для того наверно чтобы все время не создавать объект QSettings для каждого окна, а чтобы делать это централизовано. В менеджере настроек сразу определяется куда будут записываться настройки, а также происходит инициализация объекта QSettings:
m_settings(qApp->organizationName(), qApp->applicationName())
Кроме того мы сможем менять поведение менеджера на специфичесое для данного проекта.


Название: Re: Вопрос по архитектуре приложения
Отправлено: DmitryM от Июнь 08, 2012, 20:28
Мне кажется пример с кнопками и метками не совсем жизненный, и в принципе задача довольно простая чтобы с ней заморачиваться.
Вот тебе другой возможный приме:
У тебя есть физический объект, облупленный кучей датчиков. Ты с подошью обратных вызовов делаешь так, что бы сигнал с датчика обрабатывался соответствующим методом класса. Естественно что состояния этого класса меняется, и тут тебе нужно что бы все , кому нужно следить за этим событием были проинформированы.
Дальше ты можешь писать сколь угодно много обработчиков (классы Коллег).
И вот на базе медиатора получилась событийная модель.
Я предложила данное решение для задачи: Как организовать взаимодействие компонентов сложной системы, не
связывая их напрямую друг с другом. То есть получить систему разбитую на модули но со слабой связностью. Может быть существуют и другие более красивые  решения данной проблемы??
Не совсем то, но всю эту систему можно накрыть другим фасадом(Facade).


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

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

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


Название: Re: Вопрос по архитектуре приложения
Отправлено: Igors от Июнь 08, 2012, 20:44
Мне кажется пример с кнопками и метками не совсем жизненный, и в принципе задача довольно простая чтобы с ней заморачиваться.
Ну простой - да, а в жизненности ему не откажешь.

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

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

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


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

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

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

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


Название: Re: Вопрос по архитектуре приложения
Отправлено: alexis031182 от Июнь 08, 2012, 20:54
...
ЗЫ
А если кто-то будет наезжать здесь, скажите, что Вы человек Макса))     
Тогда уж лучше "от Макса" ;D

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


Название: Re: Вопрос по архитектуре приложения
Отправлено: alexis031182 от Июнь 08, 2012, 21:01
)) пока никто особо не наезжал, хотя вначале ожидала много критики
Самим бы разобраться прежде чем начинать критиковать :)


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

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


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

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


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


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

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

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


Название: Re: Вопрос по архитектуре приложения
Отправлено: m_ax от Июнь 08, 2012, 22:39
Кстати, BRE куда то пропал.. Давно его уже не видно и не слышно.. :(


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

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

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