外观模式-套餐问题

首先，肯德基提供了众多基础菜品，比如鸡翅、汉堡、薯条、沙拉、可乐等等：

这些琳琅满目的菜品虽好，但有些顾客犯了选择困难症，不知道该选什么好。

于是肯德基对这些菜品做了一定的组合，推出了各种各样的套餐。比如A套餐，包括汉堡/薯条/可乐；B套餐，包括汉堡/鸡翅/沙拉/可乐
套餐不但搭配合理，而且价钱相对便宜，顾客可以更方便地做出选择，餐厅的销量也得到了提升。

餐厅为顾客提供餐饮服务，和团队协作开发项目又有哪些相似之处呢？

假设小灰在维护一个底层模块的代码，该模块提供了5个基础功能，这些功能对外封装成了5个接口：
某一天，团队里的程序媛小红跑过来和小灰对接：


过了几天，小红又跑过来和小灰对接：

小灰的想法如下：

这里所谓的“套餐”，就是底层细粒度接口的不同组合。在保留底层接口不变的前提下，中间层为调用方提供了便利。

这正是外观模式（Facade Pattern）的设计思想：
为了使复杂的子系统更容易被使用，应当为子系统的众多接口提供一个简洁的高层接口。

上图中，几个SubSystem类对应着我们刚才所说的底层基础功能，而Facade类对应着中间层，为调用方提供“套餐”服务。

public class SubSystemA {
    public void methodA(){
        System.out.println("执行方法A");
    }
}
public class SubSystemB {
    public void methodB(){
        System.out.println("执行方法B");
    }
}

public class Facade {
 
    public void comboMethodA(){
        SubSystemA subSystemA = new SubSystemA();
        SubSystemB subSystemB = new SubSystemB();
        SubSystemD subSystemD = new SubSystemD();
        subSystemA.methodA();
        subSystemB.methodB();
        subSystemD.methodD();
    }
 
    public void comboMethodB(){
        SubSystemE subSystemE = new SubSystemE();
        SubSystemD subSystemD = new SubSystemD();
        SubSystemB subSystemB = new SubSystemB();
        subSystemE.methodE();
        subSystemD.methodD();
        subSystemB.methodB();
    }
}

public class Client {
    public static void main(String[] args) {
        Facade facade = new Facade();
        //通过外观模式，调用组合接口A
        facade.comboMethodA();
        //通过外观模式，调用组合接口B
        facade.comboMethodB();
    }
}

总结一下
外观模式特点：将子系统的逻辑和交互隐藏起来，给用户提供一个更高层次的接口。

外观模式的优点：使得系统对外部系统来说更加易用，同时也隐藏了内部具体的实现。

外观模式的场景：
1 当维护一个遗留的大系统时，这个大系统因为有功能不断叠加导致异常复杂，而新的需求又必须依赖着它，这个时候就可以为这个遗留的复杂代码提供一个外观类，让新系统与外观类交互，外观类与遗留代码交互。
2 如果维护的接口或者子系统之间相互依赖，就可以让他们通过外观接口进行通信，进而减少子系统间的耦合关系

原文链接：https://blog.csdn.net/bjweimengshu/article/details/107171436