介绍
在项目开发中，经常会碰到需要根据不同的条件采用不同的算法，但是这些不同的算法又有些类似。例如商城下单中的打折功能（打八折、五折、一折），满减功能等等。
地图中根据采用不同的出行方式计算时间、金额等等，如下图，不同的出行方式使用不同的算法计算需要花费的时间和最短的行驶距离。
结构图
那这些不同的行为，我们可以把它们封装成不同的算法，根据用户选择的不同采用不同的算法，这种可以采用策略模式来实现他们。
案例
这次的案例就采用压缩文件的案例，用户选择不同的压缩策略后台相应采用不同的压缩算法进行压缩。
**算法接口类Algorithm **
public interface Algorithm {
void compress();
}
**算法接口类实现类RarAlgorithm **
public class RarAlgorithm implements Algorithm {
@Override
public void compress() {
System.out.println("Rar压缩文件。。。");
}
}
**算法接口类实现类ZipAlgorithm **
public class ZipAlgorithm implements Algorithm {
@Override
public void compress() {
System.out.println("Zip压缩文件。。。");
}
}
算法上下文类AlgorithmContext
public class AlgorithmContext {
private Algorithm algorithm;
public AlgorithmContext(Algorithm algorithm) {
this.algorithm = algorithm;
}
public void handle(){
algorithm.compress();
}
}
业务类
public class Client {
public static void main(String[] args) {
//String type = "RarAlgorithm";
String type = "ZipAlgorithm";
AlgorithmContext algorithmContext = null;
switch (type) {
case "ZipAlgorithm":
algorithmContext = new AlgorithmContext(new ZipAlgorithm());
break;
case "RarAlgorithm":
algorithmContext = new AlgorithmContext(new RarAlgorithm());
break;
default:
break;
}
if (algorithmContext != null) {
algorithmContext.handle();
}
}
}
上面就是策略模式的代码，其实还是有优化的地方，例如下面这一段代码可以交给算法上下文类AlgorithmContext来决定，让业务类只接触AlgorithmContext，而不用接触到具体的算法类，真正的实现解耦。而下面的代码可以挪到AlgorithmContext中使用简单工厂模式实现。
switch (type) {
case "ZipAlgorithm":
algorithmContext = new AlgorithmContext(new ZipAlgorithm());
break;
case "RarAlgorithm":
algorithmContext = new AlgorithmContext(new RarAlgorithm());
break;
default:
break;
}
简单工厂模式和策略模式结合
修改后的AlgorithmContext类
public class AlgorithmContext {
private Algorithm algorithm;
//使用简单工厂模式
public AlgorithmContext(String type) {
switch (type) {
case "ZipAlgorithm":
algorithm = new ZipAlgorithm();
break;
case "RarAlgorithm":
algorithm = new RarAlgorithm();
break;
default:
algorithm = new ZipAlgorithm();
break;
}
}
public void handle(){
algorithm.compress();
}
}
业务类
public class Client {
public static void main(String[] args) {
//String type = "RarAlgorithm";
String type = "ZipAlgorithm";
//使用简单工厂模式
AlgorithmContext algorithmContext = new AlgorithmContext(type);
algorithmContext.handle();
}
}
正常来说这篇博文到这里结束了，但是仔细想想，如果增加了一个压缩算法，那么switch重是不是还要增加一个条件？那么有没有办法解决？答案是有的，java可以使用反射技术.
使用反射来替换条件判断
修改后的AlgorithmContext类
public class AlgorithmContext {
private Algorithm algorithm;
//使用简单工厂模式
public AlgorithmContext(String type) {
try {
//简单实现（可用配置文件来配置type对应的类全称）
Class clazz = Class.forName("com.dp.strategy.algorithm.impl."+type);
algorithm = (Algorithm) clazz.newInstance();
} catch (Exception e) {
algorithm = new ZipAlgorithm();
e.printStackTrace();
}
}
public void handle(){
algorithm.compress();
}
}
上面只是提供个反射思路来替换条件判断而已，正常项目开发不会用这种方式，更多的会采用配置文件的方式来获取对应的类，就像spring的配置bean一样，就是下面这种方式，有兴趣可以研究研究
<bean id="..." class="..." destroy-method="...">
<!-- collaborators and configuration for this bean go here -->
</bean>
总结
总的来说，策略模式就是将算法从业务逻辑中抽取出来，然后将选择权交给用户，这样在一定程度上提高了系统的灵活性。策略模式主要优点在于对“开闭原则”的完美支持，在不修改原有系统的基础上可以更换算法或者增加新的算法，它很好地管理算法族，提高了代码的复用性，是一种替换继承，避免多重条件转移语句的实现方式；其缺点在于客户端必须知道所有的策略类，并理解其区别，同时在一定程度上增加了系统中类的个数，可能会存在很多策略类。
那么什么时候可以使用策略模式呢？
在一个系统里面有许多类，它们之间的区别仅在于它们的行为，使用策略模式可以动态地让一个对象在许多行为中选择一种行为；一个系统需要动态地在几种算法中选择一种；避免使用难以维护的多重条件选择语句；希望在具体策略类中封装算法和与相关的数据结构。
这篇博文相关的代码
https://github.com/rainbowda/Design-Pattern/tree/master/dp-common/src/main/java/com/dp/strategy
