设计模式 - 立面

Question

Facade设计模式以“Association”为中心而不是继承，对吗？

如果有这样的汽车系统：

汽车（班级）

- ＆GT;身体（班级）

- ＆GT;转向轮（类）

- ＆GT; Chassie（班级）

- ＆GT;轮子（类）

然后这些类不是从汽车继承的吗？因为从理论上讲，我已经被教导过继承有一种“可以”的关系。“人可以成为学生”......“汽车有一个Chassie”哪个会推断它是协会？

有什么想法吗？ ：）

Answer 1

是。那是正确的。门面以协会为中心。它包含各种相关的子系统（大多数协同工作），为客户端提供有意义且简单的界面。子系统不必位于相同的继承层次结构中，但几乎总是相关联的。

你的车示例：

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

Answer 2

我同意你的看法。外观模式的想法是，您拥有一堆关联的对象，这些对象包含在外观中，以便更轻松地管理和操作这些对象。

正如Waleed Khan在评论中所说，这个例子模糊了线条，因为汽车是由不同的部分组成的。我们可能会遇到构成立面的对象都在一起工作而不直接成为某个更大实体的部分的情况。

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

Answer 3

我会不同意你的观点，门面不是以关联和遗传为中心。

  

外观是一个对象，它为更大的代码体提供了简化的界面

意味着它用于提供子系统的更高级别视图并隐藏其复杂性，无论子系统的实现是基于，关联还是继承。

Facade的另一种替代方法是transparent facade，它允许客户端通过它，并访问子系统的各个操作。

你要问的汽车系统就是一个例子，模式不仅限于此。

Answer 4

我同意下面的对象是关联还是继承的观点是一个实现细节，与模式的运作方式没什么关系。

坦率地说，Facade是一种试图完成组件化所做的事情的模式：你不能总是轻松地操纵一堆不同的东西，但你需要一个界面。您在Java世界中应用Facade的最常见示例是提供使用JavaMail接口的方法。你甚至不想处理Sessions。这很傻。同样，Spring的持久化类是一个外观，虽然它们允许你通过使用Aspects忽略会话，并且它们也引入了简化的危险，因为会话在连续调用中实际上是不同的，因此OpenSessionInView。

在想知道Facade是否适用时要问的关键问题是你能够隐藏什么？你真的能够完成它吗？

Answer 5

Facade模式是Adapter模式的变体。适配器模式“包装”接口并将其转换为另一个接口（使其适应客户端期望的形式）。通常用于使新接口适应较旧的客户端软件。或者用一个闪亮的新的，可能更干净的界面来包装旧的，狡猾的Big-Ball-O-Mud软件，并着眼于以后更换旧的Crufty代码。

另一方面，Facade模式包装一个界面，向客户端呈现简化形式。

两者都与构图与继承无关。

你想要查阅Eric Freeman和Elizabeth Freeman所着的书 Head First Design Patterns 。远比GO4书好，恕我直言，就学会用设计模式做点什么。