首先,肯德基提供了众多基础菜品,比如鸡翅、汉堡、薯条、沙拉、可乐等等:
这些琳琅满目的菜品虽好,但有些顾客犯了选择困难症,不知道该选什么好。
于是肯德基对这些菜品做了一定的组合,推出了各种各样的套餐。比如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