正面模式与SRP

Question

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

正如“四人帮”所说(尽可能接近“官方”)：

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

和

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

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

外观保护用户，使其不受系统复杂细节的影响，并为用户提供一个易于使用的简化视图。它还将使用系统的代码与子系统的细节分离开来，使以后更容易修改系统。

单一责任原则告诉我们

类或模块应该有一个(而且只有一个)需要更改的原因。

鲍勃叔叔(principle)

考虑到外观，通过设计，保护用户免受多种“改变的理由”，这两种想法怎么能一起工作呢？一个外观是否有太多的理由来改变它的实现所依赖的子系统的数量？

Answer 1

基本上，如果您的Facade类实现了依赖反转原则(它依赖于抽象，而不是具体的实现)，那么您以后就不需要修改它了。

异常--如果存在bug或需要更改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;
   }
}