Работает ли Mediator Pattern в этой ситуации?

Question

Итак, для моего текущего проекта есть три основных класса Java:

1. GUI
2. Мгновенные сообщения
3. Исчисление

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

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

Ex. Скажем, GUI хочет войти в систему пользователя, он проходит через посредника, чтобы создать поток и войти в систему, но затем посредник должен передать успех / неудачу обратно в GUI и обновить сообщение о состоянии.

Другая проблема заключается в том, что нужно обновить графический интерфейс, но не нужен модератор. Целесообразно ли просто позволить GUI создать экземпляр этого класса и запустить его, или все должно пройти через посредник?

В нашем оригинальном дизайне только что был GUI, управляющий всем, но он действительно убивал возможность повторного использования. Есть ли лучший метод проектирования для использования в этом случае?

Answer 1

Если вы обнаружите, что Observer приносит слишком много накладных расходов, возможно, лучше всего использовать Mediator. Я определенно думаю, что вы не должны иметь графический интерфейс для запуска шоу. Если вы собираетесь использовать шаблон «Посредник», сам посредник должен быть ответственным. Что-то, что вы могли бы рассмотреть, является вариантом шаблона Command. Если бы вы использовали Ruby, я мог бы рекомендовать передавать обратные вызовы функций во избежание контакта медиатора с GUI для каждой мелочи. Но поскольку это Java, может помочь некоторая форма инкапсуляции действия в стиле шаблона Command.

Answer 2

Вы также можете попытаться с помощью графического интерфейса пользователя предоставить посреднику объект обратного вызова, который обрабатывает получение возвращаемых значений или установку любых необходимых значений (версия шаблона Command). Тогда будет один на вызов от GUI к посреднику.

Другая идея состоит в том, чтобы сгруппировать методы, которые медиатор вызывает, в семантически связанные куски. В частности, если у посредника есть разделы, в которых он имеет тенденцию вызывать несколько методов графического интерфейса подряд:

   gui.a()
   gui.b()
   gui.c()

Вы можете создать один метод, который обрабатывает результат вызова всех трех. Преимущество семантически сгруппированных методов (т.е. setFileInformation над setFileMenu, setTab и т. Д.) Также в том случае, если вам нужно изменить графический интерфейс, содержимое методов может измениться, но вызов, который выполняет посредник, может не .

Answer 3

Если вы не хотите, чтобы посредник инициировал обратный вызов / уведомление, вы можете добавить обратный вызов в функцию входа в систему и сделать так, чтобы вход вызывал его по завершении.

Хотя я не знаю, как бы вы внедрили обратный вызов в Java. На языке, где функции являются гражданами первого класса, вы могли бы просто передать функцию, но вы на Java, так что я думаю, вам придется использовать шаблон команды, как предложил kmorris.