Facade 和适配器模式之间的区别是什么？

Facade 设计用于在单个服务网关后面组织多个服务。适配器的设计目的是提供一种使用已知接口访问未知接口的方法。

立面图案 wiki 页面对此有一个简短的说明。

”当包装器 必须尊重特定的接口 并且必须支持多态 行为。另一方面，表面 当一个人想要一个更容易或 更简单的界面。”

我听到一个类比，你应该想想你的通用遥控器，你已经设置工作与所有不同的立体声系统-你按“开”，它打开你的有线电视盒，你的接收器，和你的电视。也许这是一个非常高级的家庭影院，它调暗灯光，也拉窗帘。这是一个 Facade-one 按钮/函数，用于处理更复杂的步骤集。

Adapter 模式只链接两个不兼容的接口。

编辑: 适配器模式的一个快速类比(基于注释)可能类似于 DVI-to-VGA 适配器。现代的显卡通常是 DVI，但是你有一个旧的 VGA 显示器。有了一个适配器，插入到您的视频卡的预期 DVI 输入，并有自己的 VGA 输入，您将能够让您的旧显示器与您的新视频卡的工作。

适配器模式允许两个以前不兼容的接口互相工作。

Facade 模式采用一个已知的接口，即低级/细粒度接口，并用更高级/过程粒度接口包装该接口。只有一个接口，通过使用另一个接口进行包装简化了该接口。

适配器使两个接口协同工作。

Facade 将单个类公开到更高、更有限的级别。例如，视图模型 facade 可能只公开较低级别类的某些只读属性。

和往常一样，几种模式之间存在相似之处，但我认为应该是这样的:

• Facade 用于封装整个层，并提供一些方法来“方便地”访问它
• 使用了适配器，其中有两个组件应该已经在一起工作，但是由于接口中存在一些“不重要”的差异而没有一起工作。

把一个方形的木栓装进一个圆孔里。

Facade = = 运行所有内部组件的单个控制面板。

老实说，许多模式可以用相同的编程方式实现——区别在于意图。

Adapter 设计模式意味着将一个或多个类的接口“转换”为客户端期望使用的接口——适配器将把对期望接口的调用转换为被包装类使用的实际接口。

如果需要一个更简单的接口，就使用 Facade 模式(同样，也可以通过包装有问题的类以相同的方式实现)当现有接口不兼容时，你不会说你正在使用 facade，只是当你需要使它更具可读性，设计不那么糟糕，等等。

我尽量用简单明了的语言来解释，不要太拘泥于形式。

假设您已经有了一些域类，并且您希望通过 UI 与它们进行交互。Facade 可以用来提供可以从 UI 层调用的函数，这样 UI 层就不会知道除了 facade 之外的任何域类。这意味着不需要调用域类中的函数，而是从 facade 中调用单个函数，后者将负责从其他类中调用所需的函数。

另一方面，适配器可以用来集成其他外部组件，这些组件可能具有与您需要的相同功能，但是它们的函数的调用方式不完全相同。假设您的域中有一个 Car类，并且您与一个外部汽车供应商合作，该供应商也定义了一个 Car 类。在这个类中，您得到了函数 car.getDoors()，但是外部提供程序具有等效的 car.getNumDoors()。您不希望更改调用此函数的方式，因此可以使用适配器类来包装外部 Car 类，以便将对适配器的 getDoors()的调用委托给外部类的 getNumDoors()。

我一直在阅读这两种定义，它们看起来完全一样。

真的吗？

我注意到，术语 适配器有时被用来描述实际上是 策略的东西，也许是因为这个词更具表现力。

例如，在 Zend 框架中，所有的 适配器类实际上都是 策略模式的实现，因为它们只在类后面包装本机代码，以具有多种行为。

适配器通常用于包装遗留代码或“旧式”代码。

立面:

关键要点: (摘自 Pankaj Kumar 的 Journaldev文章)

1. Facade 模式更像是客户端应用程序的 帮手
2. 门面模式可以应用于任何开发点，通常是 当接口数量增加，系统变得复杂时。
3. 子系统接口不知道 Facade，它们是 应该没有任何对 Facade 接口的引用
4. 门面模式应该适用于类似的接口，它的目的是提供一个单一的接口，而不是多个接口来完成类似的工作