外观模式（Facade Pattern）隐藏系统的复杂性，并向客户端提供了一个客户端可以访问系统的接口。
这种类型的设计模式属于结构型模式，它向现有的系统添加一个接口，来隐藏系统的复杂性。
主要解决：降低访问复杂系统的内部子系统时的复杂度，简化客户端与之的接口。
使用场景： 1、客户端不需要知道系统内部的复杂联系，整个系统只需提供一个"接待员"即可。 2、定义系统的入口。
解决方法：客户端不与系统耦合，外观类与系统耦合。
应用实例：
1、去医院看病，可能要去挂号、门诊、划价、取药，让患者或患者家属觉得很复杂，如果有提供接待人员，只让接待人员来处理，就很方便 。
2、JAVA 的三层开发模式MVC 。
结合实际理解：
对于面向对象有一定基础，即使没有听说过外观模式，也完全有可能在很多时候使用它；比如java web开发的项目中有很多的service和dao，这一层service有一个非常重要的作用，就是为了方便我们管理项目中与业务逻辑相关的事物，service层同时也是组合dao层暴露给controller层或action层的功能；外观模式还完美地体现了依赖倒转原则和迪米特法则的思想，所以是很常用的模式之一。
一个形象的例子：
电脑整机是 CPU、内存、硬盘的外观。
有了外观以后，启动电脑和关闭电脑都简化了。
直接 new 一个电脑。
在 new 电脑的同时把 cpu、内存、硬盘都初始化好并且接好线。
对外暴露方法（启动电脑，关闭电脑）。
启动电脑（按一下电源键）：启动CPU、启动内存、启动硬盘
关闭电脑（按一下电源键）：关闭硬盘、关闭内存、关闭CPU
优点：
1、减少系统间的相互依赖，实现松耦合。
2、提高灵活性。（在维护一个遗留的大型系统时，可能这个系统已经非常难以维护和扩展了，这时候如果有新系统必需依赖于它就可以为新系统开发一个外观类，为高度复杂的遗留代码提供比较清晰的接口，让新系统与外观类交互，外观类与遗留代码交互所有复杂工作。）
3、降低了大型软件系统中的编译依赖性，并简化了系统在不同平台之间的移植过程。
缺点：
1、不符合开闭原则，如果要修改某一个子系统的功能，通常外观类也要一起修改。（在不引入外观类的情况下，增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”。）
2、不能很好地限制客户使用子系统，如果对客户访问子系统类做太多限制减少了可变性和灵活性。没有办法直接阻止外部不通过外观类访问子系统的功能，因为子系统类中的功能必须是公开的（根据需要决定是否使用 internal 访问级别可解决这个缺点，但外观类需要和子系统类在同一个程序集内）。
共同学习，共同进步，若有补充，欢迎指出，谢谢！