Oop '；适配器'；和'；“调解人”；模式？

我知道，适应者是一种结构模式，中介者是一种行为模式。但据我所知，这两个类所做的都是连接两个（或更多）其他类，这些类可能不兼容（不那么可维护），以便直接通信

有人能对这两者进行仔细的比较并指出确切的区别吗

这些是TutorialPoint中的链接和说明

---

这些都是来源解释

在我看来，他们没有太多共同之处

中介用于避免将多个组件耦合在一起。与每个组件直接相互“对话”（因此必须相互了解并知道如何相互沟通）不同，每个组件与单个对象对话：中介。选择这个名字是有目的的：当你和邻居吵架，无法与他沟通时，你去见一位调解人，而不是彼此交谈，你们都与调解人交谈，调解人试图解决问题

适配器用于将具有接口的对象“转换”为具有其他接口的对象。就像，例如，一个将欧洲电源插座转换成美国电源插座的电气适配器，这样你就可以在欧洲使用你的美国剃须刀。 简单示例：您需要将Runnable存储到可调用列表中。Runnable有一个run（）方法。Callable有一个方法调用（）。因此，您可以创建一个适配器：

public class RunnableAdapter implements Callable {
    private Runnable runnable;

    public RunnableAdapter(Runnable runnable) {
        this.runnable = runnable;
    }

    public void call() {
        runnable.run();
    }
}

---

适配器模式

在我们已经有两个代码基时非常有用，一个是

消费者代码

，另一个是

生产者代码

，但是

消费者

希望产品采用的格式与

生产者

代码生产的格式不同。在这里，生成代码已经就位，我们不希望修改现有代码[代码关闭以进行修改，代码打开以进行扩展]适配器类可以将生产者生产的产品转换为消费者代码期望的格式。格式可能是API，其返回类型根据生产者代码和消费者代码的期望而不同。适配器类使用生产者代码的API，并根据使用者的期望对其进行转换

现在，当我们在设计体系结构或重构时，中介模式非常有用。它有助于对象之间轻松且松散耦合的交互。定义一个对象[Mediator]，它封装了一组对象的交互方式。Mediator通过防止对象彼此显式引用来促进松散耦合，并允许您独立地改变它们的交互。

---

他已经写了一个很好的答案。我只想用更简单的话来解释区别：

• 当您不知道如何与其他对象通信或不允许您与其他对象通信时，应使用调解人

• 适配器应在您确切知道如何与对象通信时使用，但这些对象可能不支持某些通信方法或不同

有人能对这两者进行仔细的比较并指出确切的区别吗

在你的问题中引用的sourcemaking链接中的意图和清单提供了很好的洞察力

适配器将类的接口转换为客户端期望的另一个接口

Mediator通过防止对象明确地相互引用来促进松散耦合，并允许您独立地改变它们的交互

是否有某种东西隐含地意味着mediator是一个支持2个以上类的适配器。由于这个原因，中介无法充当适配器

Mediator不会将不兼容的接口转换为兼容的接口，这是客户端所期望的，与适配器不同

调解人与同一接口的同事进行交互

Mediator抽象/集中同事对象之间的任意通信

与代码示例相关的帖子：

---

如果你问我，这些假设模式的两个例子不是很有说服力，也不是他们所声称的理想方式。我会寻找一个更权威的模式来源，因为记录模式的一个关键方面是展示模式相对于其他替代方案的优点，这是这些反模式都不具备的。@barny，你能提供一些吗？哈哈，我不是模式方面的专家。有一些好的模式书。@barny无论如何我不能链接任何书，对吗？另一方面，有许多问题引用了教程中的观点解释。但是如果你仅仅因为这两个链接就建议我的问题应该被删除，这是不公平的，对吗？如果我没有引用什么呢？你说有更好的文章，当我要求你展示它们时，你说你不知道。另一方面，如果我发现那个孩子有很好的解释，我不会问这个问题。无论如何，我添加了sourcemaking解释链接。请考虑：我最喜欢的答案是：。仅供参考，我认为“比较模式X和模式Y”的每一个组合都已在SO或其他SE社区论坛上被多次询问和回答。@JB Nizet，Thanx供您解释。无论如何，在您的解释中，是否有某种东西隐含地意味着mediator是一个支持2个以上类的适配器。不，我不会这么说。