设计模式--策略模式

介绍

意图：定义一系列算法，不同算法之间可以替换，互不影响
解决问题：在多种算法相似的情况下，减少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.策略类会特别多，复用性不好。