小白学设计模式：外观模式

1、背景或问题

客户端为了完成某个功能，需要去调用某个系统中的多个模块，把它们称为是A模块、B模块和C模块吧，对于客户端而言，那就需要知道A、B、C这三个模块的功能，还需要知道如何组合这多个模块提供的功能来实现自己所需要的功能，非常麻烦。

简单来说，该模式就是把一些复杂的流程封装成一个接口供给外部用户更简单的使用。 

2、如何解决的呢？

既然不希望客户介入了解不同的模块功能细节，那就用一个模块整体负责，这个模块就是Facade。

3、为什么灵活了？

客户不需要了解流程的各个模块细节，facade提供了统一的外观：）

4、缺点

过多的或者是不太合理的Facade也容易让人迷惑，到底是调用Facade好呢，还是直接调用模块好

外观模式的本质：封装交互，简化调用。

Facade封装了子系统外部和子系统内多个模块的交互过程，从而简化外部的调用。通过外观，子系统为外部提供一些高层的接口，以方便它们的使用。

外观模式很好的体现了“最少知识原则”。

如果不使用外观模式，客户端通常需要和子系统内部的多个模块交互，也就是说客户端会有很多的朋友，客户端和这些模块之间都有依赖关系，任意一个模块的变动都可能会引起客户端的变动。

使用外观模式过后，客户端只需要和外观类交互，也就是说客户端只有外观类这一个朋友，客户端就不需要去关心子系统内部模块的变动情况了，客户端只是和这个外观类有依赖关系。

这样一来，客户端不但简单，而且这个系统会更有弹性。当系统内部多个模块发生变化的时候，这个变化可以被这个外观类吸收和消化，并不需要影响到客户端，换句话说就是：可以在不影响客户端的情况下，实现系统内部的维护和扩展。

注：

中介者模式vs外观模式

中介者模式主要用来封装多个对象之间相互的交互，多用在系统内部的多个模块之间；而外观模式封装的是单向的交互，是从客户端访问系统的调用，没有从系统中来访问客户端的调用。