外观模式（Facade pattern）

外观模式

外观模式（Facade Pattern）隐藏系统的复杂性，并向客户端提供了一个客户端可以访问系统的接口。这种类型的设计模式属于结构型模式，它向现有的系统添加一个接口，来隐藏系统的复杂性。

这种模式涉及到一个单一的类，该类提供了客户端请求的简化方法和对现有系统类方法的委托调用。

介绍

意图：为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

主要解决：降低访问复杂系统的内部子系统时的复杂度，简化客户端与之的接口。

何时使用： 1、客户端不需要知道系统内部的复杂联系，整个系统只需提供一个"接待员"即可。 2、定义系统的入口。

如何解决：客户端不与系统耦合，外观类与系统耦合。

关键代码：在客户端和复杂系统之间再加一层，这一层将调用顺序、依赖关系等处理好。

应用实例： 1、去医院看病，可能要去挂号、门诊、划价、取药，让患者或患者家属觉得很复杂，如果有提供接待人员，只让接待人员来处理，就很方便。 2、JAVA 的三层开发模式。

优点： 1、减少系统相互依赖。 2、提高灵活性。 3、提高了安全性。

缺点：不符合开闭原则，如果要改东西很麻烦，继承重写都不合适。

使用场景： 1、为复杂的模块或子系统提供外界访问的模块。 2、子系统相对独立。 3、预防低水平人员带来的风险。

注意事项：在层次化结构中，可以使用外观模式定义系统中每一层的入口。

 

以上摘录自菜鸟教程

以下为个人理解

可以看做另外一些封装，将几个步骤封装成一个你需要的步骤。

想象如下的场景

（没有外观模式）就像你去了一个陌生的地方旅游，你和当地居民沟通可能不是非常顺畅。一天你想要买一包泡面。于是你找到当地一家小卖部，然后手舞足蹈的和老板交流了半天。然后他听懂了就给了你方便面。然后你去打白开水然后你又手舞足蹈的和他说了半天。他为你打了一桶白开水。你感觉非常的尴尬和累。

（外观模式）经过几次旅游后，你决定请一个导游。你只负责看风景和玩，然后他负责其他的事。你再次要求要吃泡面，他立刻明白五分钟后泡面和白开水都给你准备好了。你热泪盈眶，你想起了上次你要泡面，老板给了你一捆手工面。你也想起了上次你要白开水老板给了你一瓶可口可乐。这样相当于，导游充当了外观因为他两边都懂。所以他可以都不出错。而当没有导游时。你直接面对源代码，而且不能马上得到结果，需要多步合并时往往费时费力还容易出错误。具体代码不赘述。