我们团队中的另一个人为我提供了一个库作为他的 web 框架的 jar。我们称这个框架为“我朋友的框架”。
我需要他的框架中的一个特定类。该类公开的一半属性是我自己的应用程序真正需要的。另一半不需要。要检索此类的属性，您需要进行一些字符串操作。因为我将在这个类之上开发自己的框架，所以我想尽可能多地解耦依赖。也许将来我的另一个朋友会开发一个更好的框架。
所以我所做的是为该类生成了一个外观类。我自己的框架通过我的外观类访问属性。如果“我朋友的框架”确实改变了，我只需要改变一个外观类，其余的保持不变。此外，字符串操作是在外观类内部完成的。此外，外观类仅公开所需的属性。所以我自己的框架只是作为普通的 getter/setter 访问属性。
然而，我和这个人发生了争执。他强迫我直接使用他的课程，因为首先他永远不会改变他的课程的实现。所以他告诉我写一个门面类真的没有任何价值。但我不同意。
我错了吗？我相信我是对的。
原则上你没有错。
你错了，你所做的不是表面。Facade 更常用于你有一个包含一堆服务的 API 的情况。您可以一起使用所有这些服务，但这可能会变得复杂。该模式是建立一个单一的 API 接口，即外观，它将服务调用协调为可用的逻辑操作。
您所做的更像是适配器模式。您正在通过在其前面放置另一个类来使他的类适应您的用例。
请注意，我只是指出一个语义问题，实际上您所做的是一个很好的设计实践。
另请注意，如果您真的不打算在未来进行更新，您可能不需要经历这些麻烦。也许 YAGNI——你不需要它。
对我来说听起来是个不错的设计。
外观通常为更大的类子系统提供接口，但我不明白为什么您不能也使用外观来访问一个复杂的类。
听起来对方可能很固执——所以我认为与他的框架脱钩是件好事。
如果您的外观更易于使用，也许您可以让他将其添加到他的框架中，以便也将其提供给其他所有人。
你的方法对我来说听起来不错。
只需确保创建一个非常独立于整个框架的实际实现的接口。其他一些人指出这是一个适配器，只是因为您试图解耦单个类，但我怀疑该类与其他类耦合。
试着回答这个问题：这个门面应该隐藏什么秘密？尝试发布一些您想要公开的方法，以便我们讨论。