问题标签 [mediator]

对于那些熟悉中介者模式的人...

我想在 Delphi 中实现 Mediator 模式，但 Delphi 编译器无法处理所需的循环引用。

查看“设计模式”中的原始 GOF 图，Mediator 对每个 Colleague 都有引用，但许多 Colleague 对象都有对 Mediator 的引用。

这在大多数语言中都不是问题，但我的 Delphi 编译器给了我'F2047 Circular unit reference to ...'

这种使用接口的方法有用吗？（看起来很复杂）

我正在使用德尔福 2010

[解决方案总结]

总结一下公认的答案：在允许循环引用的语言中，您可以省略抽象的 Mediator 类（如第 278 页 GoF 的“实现”部分所述）。在没有抽象 Mediator 类的情况下在 Delphi 中实现 Mediator 的唯一方法是将所有类放在一个 Unit中。

否则，除了具体的子类之外，您还需要一个额外的抽象 Mediator 基类。

三个单元的 Uses 子句如下所示：

ConcreteColleage1 使用中介者
ConcreteMediator 使用中介者，ConcreateColleague1
中介者（两者都不使用）

没有循环引用！

仅供参考，我在 Swing on Java 中为我的 GUI 采用了中介者模式。

不幸的是，如果用户输入需要新窗口，则总是会引发并发修改异常。

这是因为我的代码在处理来自现有同事（窗口）的用户输入的过程中，尝试将新同事（新窗口）添加到调解员的同事列表中。

例如

是否有其他一些我可以采用的处理添加新同事的结构？提前感谢您的任何建议或想法。

我听说某处@web 我将能够找到使用GUI 组件的Mediator 的良好C++ 示例。但我设法只找到了对我没有帮助的 GoF 样本或来自魔法制作之类的东西。

那么...您知道在哪里可以找到提到的 GUI 示例吗？

很抱歉这种问题，但这对其他人也很有用。

Eventbus 更像是调解者还是观察者？据谷歌称，“eventbus mediator”获得 2.430 次点击，“eventbus observer”获得 3.850 次点击。

从描述来看，它们都符合我想要做的事情（调解员甚至更多）。那么 eventbus 是否实现了特定的模式，还是由我说它是由我决定的？

我有几个需要相互交互的演示文稿中涉及的“小部件”，但交互已经变得足够复杂，以至于需要一个新对象来处理交互。

在尝试将调解器作为该对象进行工作时，我对如何有效地构建参与者感到困惑。中介者必须知道小部件，小部件必须知道中介者。

使用下面的玩具类，有人可以向我展示构造函数的外观以及它们通常以什么顺序创建？

干杯，
贝里尔

我是意大利人，很抱歉语言不好。

我正在开发基于 MVVM 的应用程序。我的解决方案包含在单个 WPF 应用程序项目 Ms、Vs 和 VM 中。作为 Views 和 ViewModels 之间的中介，我使用带有 Register 和 NotifyColleagues 方法的 Messenger 类，作为 Application 类的属性创建。

到目前为止，这一切都很好，我决定将 Ms、Vs 和 VM 划分到不同的库中。在这种情况下，不能再将 Messenger 类放在可执行文件的 Application 类中，因为库无法与它联系。

所以我该怎么做？是否有不同的调解员模式，更适合我的情况，或者我错过了什么？

谢谢你=）

我想在我的 netbeans 平台模块化应用程序中使用调解器设计模式 (http://en.wikipedia.org/wiki/Mediator_pattern)。但是，我不确定如何在启动时执行此操作，因为似乎没有一种好的方法来创建我的中介然后将其注入每个模块。

有谁知道这样做的好方法？我是否必须求助于使用 Lookup API 之类的？

来自 Robotlegs/PureMVC，我非常熟悉视图中介的概念，即一个组件，它几乎可以监听来自“虚拟”视图的事件/请求并发出进一步的请求，发送一个应用程序范围的信号/事件, 根据来自视图的请求执行命令等。

Flex 4 中引入的主机组件思想是否可以被视为与调解器相同？唯一让我有点困扰的是宿主组件仍然被认为是视图，因为它们扩展了 SkinnableComponent 或任何进一步从它继承的类。在我看来，调解员应该完全被排除在视图逻辑之外。

尽管如此，我不想为那个宿主组件编写一个皮肤、一个宿主组件和一个视图中介，因为这将是一个相当大的开销，并且会导致更多的复杂性而不是抽象。

我是否应该使用主机组件作为中介，并将应用程序级逻辑放在那里，例如应用程序级事件调度？

我正在为我的工作创建一种基于中介的库。我们创建了很多应用程序，所以我想要一些可以在每个应用程序的基础上轻松获取和修改的东西。我还希望它能够很容易地创建“小部件”（因为没有更好的术语）并且很容易删除它们而不必担心破坏任何东西。我们制作的许多这些应用程序也可以由为应用程序制作应用程序或小部件的外部开发人员扩展。

这就是我遇到中介者模式的方式。我写了一些类似这样的东西：

我有3个问题：

1. 在这种模式下，你如何/应该使用 JavaScript 处理 DOM 操作？我不希望开发人员在他们的小部件之外弄乱 DOM。

2. 您如何/应该如何处理 AJAX 请求。你应该做点什么吗？您是否应该只在库中提供 AJAX/JSONP 调用（Core在本例中）。

3. 我最大的问题是，您实际上如何与其他小部件进行交互？我不想紧耦合（显然），但我不明白你将如何与另一个小部件交互。例如，假设您有一个文本框，并在提交时将其发送到数据库。另一个小部件，让我们称之为“时间线”小部件，现在当它被提交时，然后使用文本框小部件中的文本更新时间线？

===更新===

我最终写了这个：

http://oscargodson.github.com/Core.js/

我正在用 flash AS3 和 puremvc 制作一个应用程序，正确处理视图中介的方法有点让我有点……

好的 - 我有 3 或 4 个不同的观点，每个观点都由它自己的调解人管理。每个视图仅单独显示 - 即。当 1 可见/在舞台上时 - 其他不可见/从舞台上移除（过于简化，但我想可以将其视为单独的页面，一次查看一个，导航栏允许用户在他们喜欢时更改视图）

起初，我创建并添加到舞台上的每个视图调解器都是它自己的视图组件，因此，当“轮到”显示或隐藏该视图时，它很简单 - 为其视图组件添加儿童和删除儿童。

但是，我在 puremvc.org 上读到，这不是一个好习惯。通过舞台（在我的情况下，这是每个中介的 viewComponent - 每个视图都被添加到其中 - 例如 viewComponent.addChild(foo) b. 创建自己的视图 - 这允许我首先添加和删除它.

所以我改成了推荐的方式——当我创建每个中介时，我传入的是它所管理的视图组件（而不是舞台/主文档类）

例如。

所以 - 在这种情况下 - 我不知道如何在需要时删除/添加每个视图。我可以很容易地从每个调解器中设置可见性，但我有点想避免这样做 - 宁愿在不用于资源管理时删除......

任何人都对我“打算”如何解决这个问题有任何好的想法（例如，当舞台上不再需要视图时，暂时删除它，然后在需要时添加它？） - 或者我是遗漏了一些观点（很可能！）并以错误的方式解决这个问题？我对 puremvc 很陌生，所以不太自信我正在接近它。欢迎指点！