外观设计模式的中心是“关联”而不是继承，对吗？
如果有这样的汽车系统：
车（类）
-> 身体（类）
-> 方向盘（类）
-> Chassie（类）
-> 轮子（类）
那么这些类不是从 Car 继承的吗？因为从理论上讲，我被教导继承具有“可以”关系..“人可以成为学生”......“汽车有底盘”这会推断它是关联？
有任何想法吗？:)
问问题
911 次
5 回答
1
是的。那是对的。立面以协会为中心。它包装了各种相关的子系统（它们大多一起工作），为客户端提供一个有意义且简单的接口。子系统不必处于相同的继承层次结构中，但几乎总是相关联的。
您的汽车示例：
http://www.go4expert.com/forums/showthread.php?t=5127#facade
于 2012-10-29T17:32:32.520 回答
1
我会同意你的。外观模式的想法是，您将一堆关联的对象包装在外观中，以便更轻松地管理和操作这些对象。
正如瓦利德汗在评论中所说，这个例子有点模糊了构图的界限，因为汽车是由不同的部分组成的。我们可能会遇到这样一种情况，即构成外观的对象都一起工作，而不是直接成为某个更大实体的一部分。
汽车示例使事情变得简单，因为我们可以做一些car.turnLeft()可能会影响车轮和方向盘的事情。对象之间的协调由Car.
于 2012-10-29T17:48:31.843 回答
1
我不同意你的观点，外观既不以关联为中心，也不以继承为中心。
外观是一个对象，它为更大的代码体提供简化的接口
这意味着它用于提供子系统的更高级别视图并隐藏其复杂性，无论子系统的实现是基于什么，关联或继承。
外观的另一种替代方法是transparent facade让客户端能够通过它，并访问子系统的各个操作。
你问的汽车系统只是一个例子，模式不限于此。
于 2012-10-29T18:29:24.517 回答
0
我同意下面的对象是关联还是继承是一个实现细节的观点，它与模式的功能没有太大关系。
坦率地说，Facade 是一种试图完成与组件化相同的事情的模式：你不能总是让操作一堆不同的东西变得容易，但你需要一个接口。您一直看到在 Java 世界中应用 Facade 的最常见示例是提供一种使用 JavaMail 接口的方法。您甚至不想处理 Sessions。这很傻。同样，Spring 的持久性类是一个门面，尽管它们允许您使用 Aspects 忽略会话，并且它们还引入了简化的危险，因为会话在连续调用中实际上是不同的，因此OpenSessionInView。
在想知道 Facade 是否适用时要问的关键问题是您将能够隐藏什么？你真的能做到吗？
于 2012-10-29T18:45:32.283 回答
-2
Facade 模式是 Adapter 模式的变体。适配器模式“包装”一个接口并将其转换为另一个接口（使其适应客户期望的形式）。通常用于使新界面适应较旧的客户端软件。或者用一个崭新的、大概更干净的界面来包装旧的、笨拙的 Big-Ball-O-Mud 软件，着眼于以后替换旧的笨拙的代码。
另一方面，Facade 模式包装了一个接口，将它的简化形式呈现给客户端。
两者都与组合与继承无关。
您想查阅Eric Freeman 和 Elizabeth Freeman的《 Head First Design Patterns 》一书。就学习使用设计模式做一些事情而言，远比 GO4 的书，恕我直言。
于 2012-10-29T17:31:23.693 回答