立面图案与 SRP

Question

在经典的 Facade 模式中，单个对象通常为更复杂的事物提供简化的接口。

正如四人组所说（尽可能接近“官方”......）：

Facade (185) 为子系统中的一组接口提供统一的接口。 Facade 定义了一个更高级别的接口，使子系统更易于使用。

和

...外观只是将接口抽象为子系统对象，以使它们更易于使用；它没有定义任何新功能，子系统类也不知道它。

或者，正如 Unmesh 在 https://stackoverflow.com/a/5242476 中所说的那样：

Facade 使用户免受系统复杂细节的影响，并为他们提供易于使用的简化视图。它还将使用系统的代码与子系统的细节解耦，便于以后修改系统。

单一职责原则告诉我们

一个类或模块应该有一个，而且只有一个，改变的理由。

鲍勃叔叔 (http://en.m.wikipedia.org/wiki/Single_responsibility_principle)

鉴于 Facade 在设计上可以保护用户免受众多“改变理由”的影响，这两种想法如何协同工作？ Facade 的更改理由不是与其实现所依赖的子系统的数量一样多吗？

Answer 1

基本上，如果你的 Facade 类实现了依赖倒置原则（它依赖于抽象，而不依赖于具体实现），你将不需要修改以后会的。

异常 - 如果存在错误或您需要更改 Facade 的业务逻辑（例如，它封装的那些子系统之间的交互）。但这不是 SRP 违规。

顺便说一句，似乎引用中隐含地提到了它：

Facade (185) 为子系统中的一组接口提供统一的接口

Answer 2

首先，

模式和原则 - 是两个不同的东西。模式是经过验证的问题解决方案，而原则只不过是指导方针。

因此，比较它们是没有意义的，尤其是因为它们在大多数情况下是相互补充的。

至于 SRP 的定义，“一个改变的理由”很容易解释：

如果您构建汽车对象的图像，它将由引擎、类型和类似的东西组成。因此，该对象的构造如下所示：

car = new Car(new Engine(), new Type());

如果你想更换那辆车的发动机怎么办？然后你只需替换Engine 的实例。这是改变的原因之一，因为您不会触及它的其他部分。

至于外观，您提供的定义过于笼统。外观只是包装在某些环境下可能不可用的东西的另一种方式。他们只是确保您的东西可以在所有环境中工作。例如，在 JavaScript 中有一个非常著名的事件监听器示例：

function click(object, handler){
   if (object.addEventListener != undefined){
     // For major browsers
     object.addEventListener(....);
   } else if (object.attachEvent != undefined){
     // For IE < 7
     object.attachEvent(...)
   } else {
     object.click = handler;
   }
}