思考外观模式
正常完成一个功能需要调很多个接口,外观模式就是组装这些接口为一个接口,对外提供这一个接口,用户调用这一个接口就能完成原来多个接口才能完成的功能,简化调用
1.外观模式的本质
外观模式的本质是:封装交互,简化调用。
Facade封装了子系统外部和子系统内部多个模块的交互过程,从而简化了外部的调用。通过外观,子系统为外部提供一些高层的接口,以方便它们的使用。
外观模式很好地体现了“最少知识原则”。
如果不使用外观模式,客户端通常需要和子系统内部的多个模块交互,也就是说客户端会有很多的朋友,客户端和这些模块之间都有依赖关系,任意一个模块的变动都可能会引起客户端的变动。
使用外观模式后,客户端只需要和外观类交互,也就是说客户端只有外观类这一个朋友,客户端就不需要去关心子系统内部模块的变动情况了,客户端只是和这个外观类有依赖关系。
这样一来,客户端不但简单,而且这个系统会更有弹性。当系统内部多个模块发生变化的时候,这个变化可以被这个外观类吸收和消化,并不需要影响到客户端,换句话说就是:可以在不影响客户端的情况下,实现系统内部的维护和扩展。
2.何时选用外观模式
建议在如下情况时选用外观模式。
- 如果你希望为一个复杂的子系统提供一个简单接口的时候,可以考虑使用外观模式。使用外观对象来实现大部分客户需要的功能,从而简化客户的使用。如果想要让客户程序和抽象类的实现部分松散耦合,可以考虑使用外观模式,使用外观对象来将这个子系统与它的客户分离开来,从而提高子系统的独立性和可移植性。
- 如果构建多层结构的系统,可以考虑使用外观模式,使用外观对象作为每层的入口,这样可以简化层间调用,也可以松散层次之间的依赖关系。
3.实现
模拟代码生成使用的外观模式
public class ControllerGenerate {
public void generate(){
System.out.println("controller层代码生成");
}
}
public class ServiceGenerate {
public void generate(){
System.out.println("service层代码生成");
}
}
public class DaoGenerate {
public void generate(){
System.out.println("dao层代码生成");
}
}
门面类
public class Facade {
//组装各个方法
public static void generate(){
ControllerGenerate controllerGenerate = new ControllerGenerate();
ServiceGenerate serviceGenerate = new ServiceGenerate();
DaoGenerate daoGenerate = new DaoGenerate();
controllerGenerate.generate();
serviceGenerate.generate();
daoGenerate.generate();
}
}
测试
public class FacadeTest {
/**
* 模拟代码生成过程
* 1.生成controller层
* 2.生成service层
* 3.生成dao层
* @param args
*/
public static void main(String[] args) {
ControllerGenerate controllerGenerate = new ControllerGenerate();
ServiceGenerate serviceGenerate = new ServiceGenerate();
DaoGenerate daoGenerate = new DaoGenerate();
controllerGenerate.generate();
serviceGenerate.generate();
daoGenerate.generate();
System.out.println("--------------------------------");
Facade.generate();
}
}
类图