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

[nata267]

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

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

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

[Igors]

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

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

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

[alexis031182]

Ну как сказать... Это конечно "хорошие вещи".

Что в них плохого?

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

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

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

Согласен, но у каждого свой потенциал, да и всё чаще бытует половинчатое заполнение чердака, нежели его переполнение.

[DmitryM]

Медиатор пытается решиться следующую проблему:

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

Решить такую задачу можно сигнал-слотами.

[Akon]

Медиатор на пальцах: пусть есть окно с тремя кнопками, нажав на одну, остальные тоже должны нажаться. Теперь забудем о сигналах и слотах. Решение в лоб - каждая кнопка должна знать о других, чтобы вызывать их метод press(), но вместо этого каждой кнопке подсовывается медиатор, кнопка использует медиатор для уведомления о нажатии, медиатор выполняет нажатия оставшихся кнопок.

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

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

[Krysk]

Медиатор почти тоже самое что контекст. Только в контексте не используются лишние методы взаимодействия со связанными объектами он лишь содержит ссылки на объекты ну и может быть всякие там обсерверы на случай подмены. Удобен тем, что не нужно производить подмену в каждом конкретном объекте, достаточно поменять в контексте.

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

[DmitryM]

Самое очевидное назначение медиатора это ООП альтернатива сallback! В этой роли мне больше нравятся вложенные классы Java и делегаты в C#.
Думаю, что в чистом виде он вряд ли нужен.

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

Это про паттерн State?

[Igors]

Медиатор на пальцах: пусть есть окно с тремя кнопками, нажав на одну, остальные тоже должны нажаться. Теперь забудем о сигналах и слотах. Решение в лоб - каждая кнопка должна знать о других, чтобы вызывать их метод press(), но вместо этого каждой кнопке подсовывается медиатор, кнопка использует медиатор для уведомления о нажатии, медиатор выполняет нажатия оставшихся кнопок.

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

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

[DmitryM]

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

Вот тебе example на разных ЯП включая C++.

[Igors]

Вот тебе example на разных ЯП включая C++.

Ваша эрудиция впечатляет, я бы никогда не нашел этой ссылки. И как Вы оцениваете то что там написано?

[alexis031182]

Вот тебе example на разных ЯП включая C++.

[alexis031182]

Может быть начнём с совсем простого? Гуру могут нервно покурить в сторонке, а мы пока так, сами в песочнице покопаемся.

Код:

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(), чтобы избежать этой неприятности.

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

[Igors]

Как видно, медиатор при решении данной задачи не очень-то эффективен.

Вот то-то и оно. Этот эффект очень типичен. С первого взгляда - ну вот же, тот самый случай, точно этот паттерн. Однако после того как маленько вник, попробовал - да ни фига, это или совсем другой или вообще "по мотивам".

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

[alexis031182]

Если, допустим, изменить задачу таким образом. Пусть существует некоторое кол-во кнопок (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;

};

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

[alexis031182]

Вот то-то и оно. Этот эффект очень типичен. С первого взгляда - ну вот же, тот самый случай, точно этот паттерн. Однако после того как маленько вник, попробовал - да ни фига, это или совсем другой или вообще "по мотивам".

Igors.same_opinion++;