在什么场景下，你会选择Facade pattern和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 模式的代码中使用依赖倒置。您可以将责任委托给更高级别的东西，而不是明确定义要使用的特定外观实现 - 使用像 Spring 这样的框架，您可以指定应该在应用程序的配置中使用哪个外观的细节 - 所以如果如果您决定切换到一种新的付款处理方式，您的代码不必更改 - 它使用的特定外观实现只会被其他东西替换，而您的代码不会受到更改的影响。