设计模式之外观模式理解

小A去政府办事，比如想开一家公司，需要跑很多个部门，盖N个章，如果能在一个办事窗口把所有需要的资料都提交上去，然后让办事人员去协调各个部门的公务员处理各种流程，小A只需要等一个最终结果就行，该多省事。虽然这个在现实条件下不容易实现，但在程序设计中有类似的思路，就是facade(外观)模式。

外观模式：为子系统中的一组接口提供一个一致的界面， Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。引入外观角色之后，用户只需要直接与外观角色交互，用户与子系统之间的复杂关系由外观角色来实现，从而降低了系统的耦合度。

上图形象地描述了外观模式的作用。在实际应用中，外观模式能够对客户屏蔽子系统组件，实现了子系统与客户之间的松耦合关系，但外观模式也有一个明显的缺点，就是增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”。在上面的例子中，就是如果政府出台一项新规定，科技公司可以减免税收，但需开具证明，恰好小A所开的公司是科技公司，为了享受税收优惠，小A就必须另外去开科技公司的证明，也就是客户端的行为需要做修改。

为了解决这个问题，引入了抽象外观类，客户端针对抽象外观类进行编程。对于新的业务需求，不修改原有外观类，而对应增加一个新的具体外观类，由新的具体外观类来关联新的子系统对象，同时通过修改配置文件来达到不修改源代码并更换外观类的目的。

回到开公司的例子，也就是窗口办事员只负责接收小A的资料，具体的办事流程交给后台办事员处理，如果是科技公司就交给专门负责科技公司的后台办事员处理，让他去开证明，小A只需要提交所需的材料即可。这样对小A来说，只需要提交资料，对于窗口办事员来说，不需要增加自己的工作量，只是政府需要增加一个后台办事员的编制而已。