设计模式笔记-Facade外观模式

外观模式：为很多个子系统提供一个更高层次、更简单的接口，从而降低了子系统的复杂度和依赖。实际中，定义一个Facade类，其中集合了子系统各个类对象的指针，并对Client提供一个统一的接口用来访问子系统中的一群接口，客户不用再直接和子系统中的各个类交互，那么多子系统，很麻烦，它只与外观Facade类交互。当子系统中的类进行改变时，客户端也不会像以前一样受到影响。如果用户想单独用某个子系统，也可以。这个模式可能是最简单的了，因为项目中肯定经常用，不管你有没有意识到！话不多说，贴一张网上的图就够了！

简单归简单，用的时候还是有很多细节要注意：

1.在外观模式中，通常只需要一个外观类，在很多情况下为了节约系统资源，一般将外观类设计为单例类。当然在一个系统中可以设计多个外观类，每个外观类都负责和一些特定的子系统交互，向用户提供相应的业务功能。所以上图中Facade类里的doSomething()组合哪些子系统功能（接口函数），这是由调用doSomething的用户需求定的；可以想象用户有不同的需求，那么Facade里就有doSomething1,doSomething2...等。或者重新定义一个FacadeA类，里面聚合了和Facade类不同的子系统。外观类多的话，可以抽象出一个一个抽象基类出来。

2.当增加新的子系统或者移除子系统时需要修改外观类，这违反了开闭原则，可以通过引入抽象外观类在一定程度上解决该问题，客户端针对抽象外观类进行编程。对于新的业务需求，不修改原有外观类，而对应增加一个新的具体外观类，由新的具体外观类来关联新的子系统对象，同时通过修改配置文件来达到不修改源代码并更换外观类的目的。 不要通过继承一个外观类来加入新的行为，这种做法是错误的。新的行为的增加应该通过修改原有子系统类或增加新的子系统类来实现，不能通过外观类来实现。