浅谈GoF23设计模式-“Facade”模式

在讨论外观（Facade）模式之前还是要先看一下使用该模式的动机：
当某方案的组件的客户和组件中各种复杂的子系统有了过多的耦合，随着外部客户程序和各子系统的演化，这种过多的耦合面临很多变化的挑战，因此需要一种解决方案来帮我们简化外部程序和系统间的交互接口及客户程序和内部子系统之间的依赖相互解耦，所以在这就引入了外观（Facade）模式。
“Facade”模式定义：为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

public class FacadePattern
{
    public static void main(String[] args)
    {
        Facade f=new Facade();
        f.method();
    }
}
//外观角色
class Facade
{
    private SubSystem01 obj1=new SubSystem01();
    private SubSystem02 obj2=new SubSystem02();
    private SubSystem03 obj3=new SubSystem03();
    public void method()
    {
        obj1.method1();
        obj2.method2();
        obj3.method3();
    }
}
//子系统角色
class SubSystem01
{
    public  void method1()
    {
        System.out.println("子系统01的method1()被调用！");
    }   
}
//子系统角色
class SubSystem02
{
    public  void method2()
    {
        System.out.println("子系统02的method2()被调用！");
    }   
}
//子系统角色
class SubSystem03
{
    public  void method3()
    {
        System.out.println("子系统03的method3()被调用！");
    }   
}

“Facade”模式特点：
1.）从客户程序的角度来看，Facade模式不仅简化了整个组件系统接口，同时对于组件内部于外部客户程序来说，从某种程度上也达到了一种“解耦”的效果，内部子系统的变坏不会影响到Facade接口的变化。
2.）Facade设计模式更注重从架构的层次去看整个系统，而不是单个类的层次。Facade很多时候更是一种架构设计模式。
3.）降低了大型软件系统中的编译依赖性，简化了系统在不同平台之间的移植过程，因为编译一个子系统不会影响其他的子系统，也不会影响外观对象。
结构型模式区分
Facade模式注重简化接口；
Adapted模式注重转换接口；
Bridge模式注重接口分离；
Decorator模式注重稳定的接口前提下为对象扩展功能；