使用哪种设计模式（我需要类似中介模式的东西）？答案

【问题标题】：Which design pattern to use (i need something like mediator pattern)?使用哪种设计模式（我需要类似中介模式的东西）？
【发布时间】：2012-04-27 23:49:51
【问题描述】：

我有一个带有很多控件的 GUI 应用程序。它们中的大部分都有事件，并且控件在逻辑上连接到每个那里。例如，我有 5 个组合框。如果我在 cb1 和 cb3 中选择某些东西，它们 cb2 必须更改其可用值的列表。如果我在 cb2 和 ch4 中选择某些东西，它们 cb5 必须加载其可用值列表。我在网上找到的所有文章都说在这种情况下我应该使用 mediator 模式。但是在所有这些文章中，调解员 - 就像一个上帝类，它了解所有控件的一切，并决定在发生某些事件时应该做什么。如果我有 5-6 个控制器 - 一切都很好。但是如果我有 20 或 40 个控件呢？我猜在这种情况下，中介类会变成怪物。很难用它做点什么（修改或添加新功能）。

是否有任何其他模式或中介路径的好例子，这将有助于解决这种情况？

PS：抱歉，如果已经有关于这个主题的问题 - 同名的问题太多了，从所有这些主题中找到我真正需要的东西并不容易。

【问题讨论】：

实际上 20-40 个控件可能会导致非常复杂的 Mediator。但是，Mediator 有明确的职责，这比将逻辑分散到多个类中更容易理解。您问题中的红旗不是由于20-40个控件而导致的神级风险，而是首先允许20-40个控件的GUI设计。
Fuhrmanator，我的情况是处理一些商业文件（发票、合同等）的表格很大。所以，有很多领域，用户必须使用。对于用户来说，使用一屏信息会更方便。所以，如果我试着说“好的，现在你将有 3\5 个表单\屏幕\窗口。在第一个中填写此信息，在第二个中填写该信息。”用户会找到其他一些开发者\公司，而不是改变那里的习惯。而且，无论如何，这个主题是另一个主题，我猜 :)

标签： java design-patterns architecture

【解决方案1】：

Mediator 确实是这里的正确选择，但是还有一个使用 OBSERVER 模式的替代选项，它可以让您保持逻辑分离。（cb2 观察 cb1 并做出适当的反应，cb3->cb2 等）。

使用 OBSERVER 模式，您一次只需要链接 2 个控件，这就像链。

【讨论】：

【解决方案2】：

尝试将属于一起的组件组合在自定义组件中（扩展 JComponent 或 JPanel）。这些自定义组件侦听其子级的事件并在必要时更新其他子级（-> 它们成为调解器）。自定义组件也可以触发它们自己的自定义事件，从而通知它们的父 Mediator。

【讨论】：

【解决方案3】：

Mediator pattern - Wiki

如果来自维基百科，但它很简单并且易于理解。

当我过去研究模式时，这个代码是最好的。简单而高效...对于您所描述的内容，我会使用 Mediator 模式

【讨论】：

【解决方案4】：

使用不同的动作作为策略Strategy Pattern并从Mediator调用特定的策略，这样如果你明天需要添加更多的控制器，只需要更改几行代码。

【讨论】：

【解决方案5】：

gof 书说：

" ... 相关模式

Facade (185) 与 Mediator 的不同之处在于它抽象了对象子系统以提供更方便的接口。它的协议是单向的；也就是说，Facade 对象向子系统类发出请求，反之则不然。相比之下，Mediator 实现了同事对象不提供或无法提供的协作行为，并且协议是多向的。

同事可以使用观察者 (293) 模式与中介者进行通信。 ……”。

我怀疑观察者和中介者或门面的组合会很好地工作。

请记住，设计模式的品质之一是每次你实现它们时它们都是不同的。

【讨论】：