简述
预先定义有着不同执行过程但结果相同的算法族，运行时指定所需算法。
算法族
此处为一组有共同主题的有相同结果的不同算法的集合。
话不多说，看个优化案例。
优化案例
最初版v0
不使用策略模式的案例。四种不同的计算策略。客户端的代码如下。
// 客户端
public class Client {
public static void main(String[] args) {
String target = "公园";
Scanner sc = new Scanner(System.in);
String input = sc.next();
if ("foot".equals(input)) {
System.out.println("徒步到目的地:" + target);
} else if ("bike".equals(input)) {
System.out.println("骑自行车到目的地:" + target);
} else if ("car".equals(input)) {
System.out.println("开车到目的地:" + target);
}
sc.close();
}
}
具体的条件分支都写在客户端，日后增加新的条件分支时也需要修改客户端。修改客户端这件事往往是不太愿意接受的。原因是我们希望客户端尽可能少的改变，以便减少客户使用系统的学习成本。
传统的方法就只能增加if条件判断了，如下。
修改版v1
只需修改客户端，其他代码不变。
// 客户端
public class Client {
public static void main(String[] args) {
String target = "公园";
Scanner sc = new Scanner(System.in);
String input = sc.next();
if ("foot".equals(input)) {
Foot foot = new Foot();
foot.toTarget(target);
} else if ("bike".equals(input)) {
Bike bike = new Bike();
bike.toTarget(target);
} else if ("car".equals(input)) {
Car car = new Car();
car.toTarget(target);
}
sc.close();
}
}
可以看出客户端依旧与各个具体的类耦合(从类的创建到方法的调用都是如此)。
可以使用策略模式优化，使得方法调用不需要if条件判断，传入什么样的对象就使用什么对象的行为。
修改版v2(策略模式)
public interface Trans {
void toTarget(String target)；
}
// 徒步去目的地
public class Foot implements Trans {
＠Override
public void toTarget(String target) {
System.out.println("徒步到目的地:" + target);
}
}
// 骑自行车去目的地
public class Bike implements Trans {
＠Override
public void toTarget(String target) {
System.out.println("骑自行车到目的地:" + target);
}
}
// 开车去目的地
public class Car implements Trans {
＠Override
public void toTarget(String target) {
System.out.println("开车到目的地:" + target);
}
}
// 上下文类，根据客户端业务的需求持有不同的计算对象
public class Context {
private Trans trans;
public Context(Trans trans) {
this.trans = trans;
}
// 更改持有的计算对象
public change(Trans trans) {
this.trans = trans;
}
// 实际调用持有的trans实现计算
public int toTarget(String target) {
return trans.toTarget(target);
}
}
修改后，客户端代码调用。
// 客户端
public class Client {
public static void main(String[] args) {
String target = "公园";
Scanner sc = new Scanner(System.in);
String input = sc.next();
Context context = null;
if ("foot".equals(input)) {
context = new Context(new Foot());
} else if ("bike".equals(input)) {
context = new Context(new Bike());
} else if ("car".equals(input)) {
context = new Context(new Car());
}
System.out.println(context.toTarget(target));
sc.close();
}
}
代码量确实有一定的减少，但是客户端代码从只与各个具体Trans类的实现类耦合到多耦合一个上下文类，这样想与我们的需求背道而驰啊。实际上，单纯的策略模式就是如此，只负责减少方法调用的if语句，而不设计对象创建的封装与优化。
说到对象创建的优化，就得说到工厂模式了，事实上在使用策略模式时，为了创建对象也变得方便，通常也会使用到工厂模式进行优化。详情看以下优化案例。
修改版v3(策略+简单工厂)
现有代码都不需要改变，只需要使用简单工厂封装上下文对象的创建即可。
// 工厂类，创建持有不同Trans对象的上下文对象
public class Factory {
public static Context create(String input) {
if ("foot".equals(input)) {
return new Context(new Foot());
} else if ("bike".equals(input)) {
return new Context(new Bike());
} else if ("car".equals(input)) {
return new Context(new Car());
}
return null;
}
}
修改后，客户端代码调用。
// 客户端
public class Client {
public static void main(String[] args) {
String target = "公园";
Scanner sc = new Scanner(System.in);
Context context = Factory.create(sc.next());
System.out.println(context.toTarget(target));
sc.close();
}
}
客户端代码大幅减少，并且客户端中仅仅与Context类存在耦合。创建与使用的核心逻辑都从客户端剥离，且具体调用的方法也只有在运行时才知晓(核心目的)。这样就能少些很多if语句了。
总结
优点
- 可以大幅减少if语句的书写。
- 增加新的实现方法也不需要修改客户端代码，只需要增加实现类。
缺点
-
单纯的策略模式需要客户端对于各个实现类有足够的了解，提升了开发时对系统的理解难度。
-
策略过多时，存在策略膨胀的问题。鉴于策略膨胀问题，应该慎用策略模式。这是使用混合模式或许可以解决这个问题。
混合模式
即在策略模式的实现类的方法中使用if语句分割各个情况。
适用场景
- 想要优化系统中过多的
if语句时。