设计模式-外观

Question

外观设计模式以“关联”为中心，而不是继承，对吗？

如果有这样的汽车系统：

汽车(类)

->主体(类)

->方向盘(类)

->机箱(类)

->控制盘(类)

那么这些类不是从Car继承的，对吧？因为在理论上，我被教导继承有一种“可以是”的关系..“人可以是学生”..."Car HAS a Chassie“可以推断它是联想？

有什么想法吗？:)

Answer 1

我同意下面的对象是关联还是继承的观点，这是一个实现细节，与模式如何工作没有太大关系。

坦率地说，Facade是一种试图完成组件化所做的相同事情的模式:您不能总是使操作一堆不同的东西变得容易，但您需要一个接口。您在Java界中看到的一直应用Facade的最常见示例是提供一种使用JavaMail接口的方法。你甚至不想和Sessions打交道。这太愚蠢了。同样，Spring的持久性类是一个外观，尽管它们允许您通过使用方面忽略会话，而且它们还引入了简化的危险，因为会话在后续调用中实际上是不同的，因此是OpenSessionInView。

在想知道Facade是否适用时要问的关键问题是，您将能够隐藏什么？你真的能做到吗？

Answer 2

是。这是正确的。Facade是以关联为中心的。它包装了各种相关的子系统(它们大多一起工作)，为客户端提供了一个有意义的简单接口。子系统不需要在相同的继承层次结构中，但几乎总是关联的。

您的汽车示例：

http://www.go4expert.com/forums/showthread.php?t=5127#facade

Answer 3

我同意你的观点。外观模式的思想是，您有一组关联的对象，您可以将它们包装在外观中，以使管理和操作这些对象变得更容易。

正如Waleed Khan在评论中所说，这个例子模糊了成分的界限，因为汽车是由不同的部件组成的。我们可能会遇到这样一种情况，组成外观的对象都在一起工作，而不是直接作为某个较大实体的部分。

汽车的例子让事情变得简单，因为我们可以做像car.turnLeft()这样的事情，这可能会同时影响轮子和方向盘。对象之间的协调由Car处理。