design-patterns - 编程设计模式: Facade or Not?

Question

我们团队中的另一个人为我提供了一个库作为他的 Web 框架的 jar。我们将此框架称为“我 friend 的框架”。

我需要从他的框架中获取一个特定的类。该类公开的属性中有一半是我自己的应用程序真正需要的。另一半则不需要。要检索此类的属性，您需要执行一些字符串操作。由于我将在此类之上开发自己的框架，因此我想尽可能地解耦依赖关系。也许将来我的另一个 friend 会开发出更好的框架。

所以我所做的是为该类生成一个外观类。我自己的框架通过我的外观类访问属性。如果“我 friend 的框架”确实发生了变化，我只需更改一个外观类，其余部分保持不变。此外，字符串操作是在外观类内部完成的。此外，外观类仅公开所需的属性。所以我自己的框架只是像普通的 getter/setter 一样访问属性。

但是，我和这个人发生了争执。他强制我直接使用他的类，因为首先他永远不会改变他的类的实现。所以他告诉我，编写门面类确实没有任何值(value)。但我不同意。

我错了吗？但我确实相信我是对的。

Answer 1

原则上你没有错。

你错了，你所做的不是一个门面。 Facade 更常用于拥有包含大量服务的 API 的情况。您可以一起使用所有这些服务，但这可能会变得复杂。该模式是建立一个单一的 API 接口(interface)，即外观，它将服务调用协调为可用的逻辑操作。

您所做的更像是适配器模式。您可以通过在他的类前面放置另一个类来使他的类适应您的用例。

注意，我只是指出一个语义问题，实际上你所做的是一个很好的设计实践。

另请注意，如果您确实不打算在将来进行更新，则可能不需要经历这个麻烦。也许 YAGNI ——你不会需要它。