在什么情况下，你会选择Facade模式和DI？

Question

请告诉Facade模式和DI的实时场景。我可以用Facade Pattern替换DI吗？

Answer 1

Facade模式用于简化与（可能）复杂子系统的交互。

一个现实世界的例子可能类似于银行系统中的PaymentFacade。

对于此示例，作为开发人员，您需要一个简单的界面，您可以调用该界面进行付款 - 即您只需为其支付一个帐号，以及要付款的帐号，以及付款金额并处理付款。但是，幕后发生的实际过程要复杂得多，它涉及各种子系统和遗留组件。首先，它需要检查帐户是否有效，然后需要检查帐户余额是否足以支付付款，它必须指示付款处理系统处理它等。

因此处理付款的实际代码可能如下所示：

accountService.validateAccountNumber(toAccount);
int balance = accountService.getBalance(fromAccount);

if (balance < paymentAmount) {
    raiseError("Insufficient funds");
}

paymentService.processPayment(fromAccount, toAccount, paymentAmount)

您拥有的第一个选项是在整个系统中复制此代码，并希望每个编写支付处理代码的开发人员都记住要访问所有相关的子系统。或者，您可以创建一个PaymentFacade来封装所有这些逻辑并隐藏其背后的复杂性 - 因此您只需调用外观上的单个方法来处理付款。

paymentFacade.processPayment(fromAccount, toAccount, paymentAmount);

另一方面，Dependency inversion与Facade模式不同，你无法比较两者或使用一个替代另一个。

依赖性反转有助于解耦软件模块。但是，您可以在使用Facade模式的代码中使用依赖项反转。不是明确定义要使用哪个特定的Facade实现，而是可以将其责任委托给更高级别的东西 - 使用像Spring这样的框架，您可以指定应用程序配置中应该使用哪个Facade的详细信息 - 所以如果你曾经决定改用一种新的处理付款方式，你的代码不必改变 - 它使用的特定外观实现只会被其他东西换掉，而你的代码不受更改的影响。