介绍
意图:定义一系列算法,不同算法之间可以替换,互不影响
解决问题:在多种算法相似的情况下,减少If…else…的使用
使用:一个系统中有很多类,而区分他们的只是行为
UML类图
这是百度上的策略模式类图,Context上下文中需要使用某种算法,根据需求不同使用不同类型的算法,所以将算法抽出来封装成Strategy和实现类。
应用
最近做个新需求,原来的产品是请假时只判断需不需要有附件就行,新逻辑是不同的假别需要有不同的附件校验逻辑,例如:假A的校验是逻辑A,假B的校验是逻辑B,每种假别都需要个If…else…去判断走哪个逻辑,如果多一种假别又需要增加个if…else…,于是就想到了使用策略模式,只需要一个附件校验实现类即可,对原逻辑不用改动,不影响其他正常逻辑。下面是的类图:
请假申请
public class ApplyVacation(){
ArgsCheck check;
public void apply(){
//参数校验
check.argsCheck();
//其他逻辑
}
}
各种校验类
public class ArgsCheck{
AttachmentBase attachment;
public void argsCheck(){
attachment.check();
//其他校验
}
public void setAttachment(AttachmentBase attachment){
this.attachment = attachment;
}
//其他校验...
}
附件校验基类接口
public interface AttachmentBase{
void check();
}
假A附件校验类
public class AttachmentVacationA implements AttachmentBase{
public void check(){
//假A校验逻辑
}
}
假B附件校验类
public class AttachmentVacationB implements AttachmentBase{
public void check(){
//假B校验逻辑
}
}
以上就是大体设计,主要是将附件校验逻辑拆出来,然后不同假别去定义不同的策略类,用到假A进行set假A就行,用到其他假别也进行set,使用时可以动态的去改变。
总结
优点
1.扩展性好,增加其他假别后只需要增加相应策略即可;
2.算法可动态切换
3.避免if else(维护性不好)
缺点
1.所有策略类都需对外暴露(违反迪米特法则)
2.策略类会特别多,复用性不好。