外观模式

前言

从应用场景出发，如果一个方法由多个不同的子方法组成，且这个方法的组成结构可能会发生变化，这个时候就需要使用外观模式。例如，从多个存储获取配置文件信息，或者是定时的异步补偿策略等等等等，几乎在所有场景都可以使用外观模式来屏蔽底层的差异。

简例

假设在一个商店里有Tom和Jerry两个商贩，每年年底都商店要求员工做年底总结，看下各位的KPL。
定义Tom的KPI

public class Tom {

    public void KPI(){
        System.out.println("今年计划卖100份橘子汁，实际卖了100份");
    }
}

定义Jerry的KPI

public class Jerry {

    public void KPI(){
        System.out.println("今年计划卖100份小吃，实际卖了50份");
    }
    
}

定义KPI外观类

public class KPIFacade {

    public static void main(String[] args) {
        KPIFacade kpiFacade = new KPIFacade();
        kpiFacade.KPI();
    }

    public void KPI(){
        Jerry jerry = new Jerry();
        Tom tom = new Tom();
        tom.KPI();
        jerry.KPI();
    }
}

如果老板突然想说两句

public class Boss {
    
    public void KPI(){
        System.out.println("今年Tom干的不错!");
    }
}

外观类也需要修改

public class KPIFacade {

    public static void main(String[] args) {
        KPIFacade kpiFacade = new KPIFacade();
        kpiFacade.KPI();
    }

    public void KPI(){
        Jerry jerry = new Jerry();
        Tom tom = new Tom();
        tom.KPI();
        jerry.KPI();
        Boss boss = new Boss();
        boss.KPI();
    }
}

输出结果

今年计划卖100份橘子汁，实际卖了100份
今年计划卖100份小吃，实际卖了50份
今年Tom干的不错!

完美的年终总结

屏蔽底层是为了自上而下的设计

底层的差异是无法避免的，无论是硬件上不同CPU的架构，还是软件上不同的实现。
屏蔽底层差异是一件大家都在做的事，Java更是其中的集大成者，因此在我们享受使用同一个语言在不同的环境去解决问题的便利时，是不是要考虑一下也沿用一下这个设计思想，让我们的代码也变得简洁易扩展，只需要维护者去自上而下解决业务问题。