设计模式——外观模式-蒲公英云

设计模式——外观模式

1.外观模式
为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
一个客户类需要和多个业务类交互，由于涉及到的类比较多，导致使用时代码较为复杂。外观模式通过引入一个新的外观类(Facade)来实现该功能，该外观类的实例负责和子系统中类的实例打交道。

2.UML类图

Center

外观模式包括两种角色：
子系统（Subsystem）：子系统是若干个类的集合，这些类的实例协同合作为用户提供所需要的功能，子系统中任何类都不包含外观类的实例引用。
外观（Facade）：外观是一个类，该类包含子系统中全部或部分类的实例引用，当用户想要和子系统中的若干个类的实例打交道时，可以代替地和子系统的外观类的实例打交道。
3.举例
作为一个android程序员，我们知道，要开发app，我们需要一台电脑、一个ide环境、一个手机。好了，上代码

public class AndroidDeveloper { public void tools() { new Computer().name(); new Ide().name(); new Phone().name(); } } //子系统角色 class Computer { public void name() { System.out.println("Computer is Lenovo!"); } } class Ide { public void name() { System.out.println("IDE is Android Studio!"); } } class Phone { public void name() { System.out.println("Phone is Mi!"); } }
//使用模式 public class FacadeTest { public static void main(String[] args) { AndroidDeveloper developer=new AndroidDeveloper(); developer.tools(); } }

4.使用场景
● 对于一个复杂的子系统，需要为用户提供一个简单的交互操作。
● 客户端程序与多个子系统之间存在很大的依赖性。引入外观类可以将子系统与客户端解耦，从而提高子系统的独立性和可移植性。
● 在层次化结构中，可以使用外观模式定义系统中每一层的入口，层与层之间不直接产生联系，而通过外观类建立联系，降低层之间的耦合度。
5.总结
外观模式优点：
● 减少客户端所需处理的对象数目，使得子系统使用起来更加容易。
● 实现了子系统与客户端之间的松耦合关系。
● 一个子系统的修改对其他子系统没有任何影响，而且子系统内部变化也不会影响到外观对象。
外观模式缺点：
● 不能很好地限制客户端直接使用子系统类，如果对客户端访问子系统类做太多的限制则减少了可变性和灵活性。
● 如果设计不当，增加新的子系统可能需要修改外观类的源代码，违背了开闭原则

参考：

http://blog.csdn.net/lmj623565791/article/details/25837275

http://blog.csdn.net/yanbober/article/details/45476527