编程设计模式：门面与否？答案

【问题标题】：Programming Design Patterns: Facade or Not?编程设计模式：门面与否？
【发布时间】：2010-12-10 16:44:31
【问题描述】：

我们团队的另一个人为我提供了一个库作为他的 Web 框架的 jar。我们称这个框架为“我朋友的框架”。

我需要他的框架中的一个特定类。该类公开的一半属性是我自己的应用程序真正需要的。另一半不需要。要检索此类的属性，您需要进行一些字符串操作。因为我将在这个类之上开发自己的框架，所以我想尽可能多地解耦依赖。也许将来我的另一个朋友会开发一个更好的框架。

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

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

我错了吗？不过我相信我是对的。

【问题讨论】：

“他强迫我直接使用他的课”。如何？他在给你打代码吗？
我认为你是对的。听起来你是更聪明的开发人员（如果，也许，给自己做一些额外的工作）。 hvgotcodes 的答案涵盖了我可能说的所有内容。我们一直将 API 封装在适配器类中——这次唯一奇怪的是你的朋友正在编写它。
是的，您实际上是在对接口进行编码，然后为他的组件编写适配器。听起来不错。但是，（可能是由于“属性”的模糊概念），您可能希望接口不仅仅是 getter 和 setter ......只是一个想法......

【解决方案1】：

原则上你没有错。

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

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

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

另外请注意，如果您真的不打算在未来进行更新，您可能不需要经历这些麻烦。也许 YAGNI——你不需要它。

【讨论】：

我认为你是对的。从语义上讲，它实际上是一个适配器模式。我只是真的不信任另一个团队的另一个人。他不得不坚持自己的框架，而不是使用众所周知的框架。我认为我的犹豫是有道理的:)

【解决方案2】：

对我来说听起来是个不错的设计。

外观通常为更大的类子系统提供接口，但我不明白为什么您不能同时使用外观来访问一个复杂的类。

听起来对方可能很固执——所以我认为与他的框架解耦是件好事。

如果您的外观更易于使用，也许您可以让他将其添加到他的框架中，以便也提供给其他人。

【讨论】：

【解决方案3】：

你的方法对我来说听起来不错。

只要确保您创建的接口非常独立于整个框架的实际实现即可。其他人指出这是一个适配器，只是因为您试图解耦单个类，但我怀疑该类与其他类耦合。

试着回答这个问题：这个门面应该隐藏什么秘密？尝试发布一些您想公开的方法，以便我们讨论。

【讨论】：

这确实只是解耦了一个类，但是这个 Adapter 类是整个框架的核心。它本质上是模型容器。我没有为模型传输单个属性或属性数组，而是传输一个模型类来包含所有需要的属性。这就像不是在您的方法周围传输 xml，而是传输 POJO 等效项。