外观模式
外观模式属于结构型设计模式.
简单来说外观模式就是一个比较牛逼的封装理解而已.将一系列的操作,功能封装在一起,供外部调用,外部调用者不关心内部实现细节.
比如常规开发中的网络框架封装,会定义一个顶层的类,将一系列的请求方法,缓存处理,tag标识等全部封装在一个类暴露方法给外部使用者调用,这样即便在后期我们更换了网络框架,所修改的也仅仅只是最顶层的类,而不会影响到外部的调用.
应用场景
- 为复杂的模块提供外部访问模块
- 各个模块相互独立,可封装在一起
- 如果是层次结构,可定义每一个层次之间的接口,将层次之间的耦合降低
代码示例
现在有3个同学,A同学会唱歌/跳舞,B同学会跳舞和弹钢琴,C同学会格斗.
在学校表演上,跳舞的同学要全部去跳舞,唱歌的唱歌,弹钢琴的弹钢琴,格斗的格斗.
常规设计外部使用者需要分别对每一个同学调用方法.
看外观模式如何使用封装解决问题
(一)每个同学的特长
- StudentA
public class StudentA {
public StudentA() {
}
public void dance() {
System.out.println("跳舞的同学:StudentA");
}
public void sing() {
System.out.println("唱歌的同学:StudentA");
}
}
- StudentB
public class StudentB {
public StudentB() {
}
public void dance() {
System.out.println("跳舞的同学:StudentB");
}
public void playThePiano() {
System.out.println("弹钢琴的同学:StudentB");
}
}
- StudenC
public class StudentC {
public StudentC() {
}
public void combat() {
System.out.println("格斗的同学:StudentC");
}
}
(二)将具有同样特长的同学封装在外观中
public class Facade {
private StudentA studentA;
private StudentB studentB;
private StudentC studentC;
public Facade() {
studentA=new StudentA();
studentB=new StudentB();
studentC=new StudentC();
}
public Facade(StudentA studentA, StudentB studentB, StudentC studentC) {
this.studentA = studentA;
this.studentB = studentB;
this.studentC = studentC;
}
//跳舞的同学
public void dance(){
studentA.dance();
studentB.dance();
}
//唱歌的同学
public void sing(){
studentA.sing();
}
//唱歌的同学
public void playThePiano(){
studentB.playThePiano();
}
//格斗的同学
public void combat(){
studentC.combat();
}
}
调用方式
Facade facade=new Facade();
facade.dance();
facade.sing();
facade.playThePiano();
facade.combat();
显示结果
跳舞的同学:StudentA
跳舞的同学:StudentB
唱歌的同学:StudentA
弹钢琴的同学:StudentB
格斗的同学:StudentC
总结
- 优点
- 内部细节改变只需修改外观类,不影响外部使用者的调用
- 外部使用者不必关心具体核心内部实现过程,只需要关心和外观的交接
- 缺点
- 如果外观类不抽象,增加新的功能模块,需要修改外观类和客户端新增调用方式,违背了【开闭原则】
外观模式就是一个封装,通过松散的耦合解决客户端的使用便捷性以及后期的维护更新.
唯一缺点【开闭原则】在后期维护以及便捷性的比较来说上个人觉得不算太大缺点,凡事都是有利有弊,各自取舍即可.
