门面模式与SRP

Question

在经典的Facade模式中,单个对象通常为更复杂的东西提供简化的界面.

正如四人帮所说的那样(尽管接近"官方"......):

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

和

...一个外观只是抽象出子系统对象的接口,使它们更容易使用; 它没有定义任何新功能,子系统类也不知道它.

或者,正如Unmesh将其放在/sf/answers/366973351/中:

Facade保护用户免受系统的复杂细节的影响,并为他们提供易于使用的简化视图.它还将使用系统的代码与子系统的细节分离,使以后更容易修改系统.

单一责任原则告诉我们

一个类或模块应该只有一个改变的理由.

Per Bob叔叔(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;
   }
}