编程设计模式：门面模式还是不用？

Question

4

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

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

因此，我为该类生成了一个外观类。我的框架通过我的外观类访问属性。如果“我的朋友的框架”发生变化，我只需更改一个外观类即可，其余内容保持不变。此外，字符串操作在外观类内部完成。此外观类仅公开所需属性。因此，我的框架只需像普通的getter/setter一样访问属性。

然而，我和这个人有过争论。他强迫我直接使用他的类，因为首先他永远不会更改他的类的实现方式。因此，他告诉我编写外观类没有任何价值。但我不同意。

我错了吗？虽然我相信自己是对的。

- chris

2

他强制让我直接使用他的类。怎么做？他在为你打代码吗？ - S.Lott

1

我认为你是对的。听起来你是更聪明的开发者（如果可能的话，也许会给自己多做一些工作）。hvgotcodes的回答涵盖了我可能说的一切。我们经常在适配器类中包装API——这次唯一奇怪的部分是你的朋友正在编写它。 - Cody Gray

是的，你基本上是在编写接口代码，然后为他的组件编写适配器。听起来不错。但是，由于“属性”概念模糊不清，你可能希望接口不仅仅是获取器和设置器...只是一个想法... - lijie

3个回答

1

听起来对我来说是一个很好的设计。

门面通常为一组类提供接口，但我不明白为什么你不能使用门面来访问一个复杂的类。

听起来另一个人可能很固执 - 所以我认为从他的框架中解耦是好的。

如果你的门面更容易使用，也许你可以让他将其添加到他的框架中，以便向其他人提供。

- nimblegorilla

其实他很固执，因为他想要自动生成我正在开发的框架。他声称自动生成我创建的适配器类（当它只是一个简单的包装器）比他拥有的更困难。 - chris

1

你的方法听起来不错。

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

尝试回答问题：这个外观应该隐藏哪些秘密？尝试发布一些您想要公开的方法，以便我们讨论。

- fabrizioM

这确实是解耦单个类，但适配器类是整个框架的核心。它本质上是模型容器。我不是传输模型的单个或数组属性，而是传输一个包含所有所需属性的模型类。就像您不是在方法之间传输xml，而是传输POJO等效项一样。 - chris

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- hvgotcodes · Accepted Answer

在原则上，你并没有做错。

但你的问题在于，你所做的不是facade。Facade通常用于有多个服务的API情况下。虽然你可以同时使用这些服务，但这样会变得很复杂。该模式的解决方案是启动一个单一的API接口，即facade，它协调服务调用以进行可用的、逻辑上的操作。

而你所做的更像是Adapter模式。你通过在其前面放置另一个类来将他的类适应于你的用例。

请注意，我仅指出了语义问题，在实践中，你所做的是一个良好的设计实践。

另请注意，如果你真的不打算在未来更新，那么你可能不需要费心去做这些。也许YAGNI--你不需要它。