定义：策略模式定义了一系列的算法，并将每一个算法封装起来，而且使它们还可以相互替换。策略模式让算法独立于使用它的客户而独立变化。
如果我们往一个方法当中插入随便一段独立的(算法)代码，就是策略模式。
比如，原来的类是这个样子：
public class MyClass {
public void myMethod(){
System.out.println("方法里的代码");
//在这插入一段代码，而且这个代码是可以随意改变的
System.out.println("方法里的代码");
}
}
我们可以设计一个接口，并当做参数传进去，就能达到这个效果。
public interface MyInterface {
//我想插入的代码
void insertCode();
}
然后把这个接口当作参数传递给原来的类：
public class MyClass {
public void myMethod(MyInterface myInterface){
System.out.println("方法里的代码");
//这个位置插进来一段代码，而且这段代码是可以随便改变的
myInterface.insertCode();
System.out.println("方法里的代码");
}
}
我们只要实现了MyInterface这个接口，在insertCode方法中写入我们想要插进去的代码，再将这个类传递给myMethod方法，就可以将我们随手写的代码插到这个方法当中。
class InsertCode1 implements MyInterface{
public void insertCode() {
System.out.println("我想插进去的代码，第一种");
}
}
class InsertCode2 implements MyInterface{
public void insertCode() {
System.out.println("我想插进去的代码，第二种");
}
}
这样我们在调用myMethod方法时就可以随意往里面插入代码了。
//客户端调用
public class Client {
public static void main(String[] args) {
MyClass myClass = new MyClass();
myClass.myMethod(new InsertCode1());
System.out.println("--------------------");
myClass.myMethod(new InsertCode2());
}
}
策略模式定义和封装了一系列的算法，它们是可以相互替换的，也就是说它们具有共性，而它们的共性就体现在策略接口的行为上，另外为了达到让算法独立于使用它的客户而独立变化的目的，我们需要让客户端依赖于策略接口。
左边是一个上下文，会拥有一个策略，右边是策略接口以及它的实现类，而上下文中具体策略是哪一种，我们是可以随意替换的。
用代码来标识类图中的关系：
首先是策略接口以及它的实现类：
package net;
public interface Strategy {
void algorithm();
}
class ConcreteStrategyA implements Strategy{
public void algorithm() {
System.out.println("采用策略A计算");
}
}
class ConcreteStrategyB implements Strategy{
public void algorithm() {
System.out.println("采用策略B计算");
}
}
class ConcreteStrategyC implements Strategy{
public void algorithm() {
System.out.println("采用策略C计算");
}
}
下面是上下文，拥有一个策略接口：
package net;
public class Context {
Strategy strategy;
public void method(){
strategy.algorithm();
}
public void setStrategy(Strategy strategy) {
this.strategy = strategy;
}
}
method方法是上下文类的一个公开方法，暂且取名为method，实际当中一般会和业务相关，下面我们使用测试类调用一下：
package net;
public class Client {
public static void main(String[] args) throws Exception {
Context context = new Context();
context.setStrategy(new ConcreteStrategyA());
context.method();
context.setStrategy(new ConcreteStrategyB());
context.method();
context.setStrategy(new ConcreteStrategyC());
context.method();
}
}
测试类中替换了两次策略，但是调用方式不变，运行结果如下：
用一个实际的例子，比如要做一个商店的收银系统，这个商店有普通顾客，会员，超级会员以及金牌会员的区别，四种顾客分别采用原价，八折，七折和半价的收钱方式，并且一个顾客每在商店消费1000就增加一个级别，那么我们就可以使用策略模式，因为策略模式描述的就是算法的不同，而且这个算法往往非常繁多，并且可能需要经常性的互相替换。
首先要有一个计算价格的策略接口:
public interface CalPrice {
//根据原价返回一个最终的价格
Double calPrice(Double originalPrice);
}
四种计算方式：
class Common implements CalPrice{
public Double calPrice(Double originalPrice) {
return originalPrice;
}
}
class Vip implements CalPrice{
public Double calPrice(Double originalPrice) {
return originalPrice * 0.8;
}
}
class SuperVip implements CalPrice{
public Double calPrice(Double originalPrice) {
return originalPrice * 0.7;
}
}
class GoldVip implements CalPrice{
public Double calPrice(Double originalPrice) {
return originalPrice * 0.5;
}
}
客户类，需要客户类帮我们完成客户升级的功能：
//客户类
public class Customer {
private Double totalAmount = 0D;//客户在本商店消费的总额
private Double amount = 0D;//客户单次消费金额
private CalPrice calPrice = new Common();//每个客户都有一个计算价格的策略，初始都是普通计算，即原价
//客户购买商品，就会增加它的总额
public void buy(Double amount){
this.amount = amount;
totalAmount += amount;
if (totalAmount > 3000) {//3000则改为金牌会员计算方式
calPrice = new GoldVip();
}else if (totalAmount > 2000) {//类似
calPrice = new SuperVip();
}else if (totalAmount > 1000) {//类似
calPrice = new Vip();
}
}
//计算客户最终要付的钱
public Double calLastAmount(){
return calPrice.calPrice(amount);
}
}
客户端调用，系统会帮我们自动调整收费策略
//客户端调用
public class Client {
public static void main(String[] args) {
Customer customer = new Customer();
customer.buy(500D);
System.out.println("客户需要付钱：" + customer.calLastAmount());
customer.buy(1200D);
System.out.println("客户需要付钱：" + customer.calLastAmount());
customer.buy(1200D);
System.out.println("客户需要付钱：" + customer.calLastAmount());
customer.buy(1200D);
System.out.println("客户需要付钱：" + customer.calLastAmount());
}
}
运行以后会发现，第一次是原价，第二次是八折，第三次是七折，最后一次则是半价。我们这样设计的好处是，客户不再依赖于具体的收费策略，依赖于抽象永远是正确的。不过上述的客户类实在有点难看，尤其是buy方法，我们可以使用简单工厂来稍微改进一下它。我们建立如下策略工厂。
//我们使用一个标准的简单工厂来改进一下策略模式
public class CalPriceFactory {
private CalPriceFactory(){}
//根据客户的总金额产生相应的策略
public static CalPrice createCalPrice(Customer customer){
if (customer.getTotalAmount() > 3000) {//3000则改为金牌会员计算方式
return new GoldVip();
}else if (customer.getTotalAmount() > 2000) {//类似
return new SuperVip();
}else if (customer.getTotalAmount() > 1000) {//类似
return new Vip();
}else {
return new Common();
}
}
}
客户类:
//客户类
public class Customer {
private Double totalAmount = 0D;//客户在本商店消费的总额
private Double amount = 0D;//客户单次消费金额
private CalPrice calPrice = new Common();//每个客户都有一个计算价格的策略，初始都是普通计算，即原价
//客户购买商品，就会增加它的总额
public void buy(Double amount){
this.amount = amount;
totalAmount += amount;
/* 变化点，我们将策略的制定转移给了策略工厂，将这部分责任分离出去 */
calPrice = CalPriceFactory.createCalPrice(this);
}
//计算客户最终要付的钱
public Double calLastAmount(){
return calPrice.calPrice(amount);
}
public Double getTotalAmount() {
return totalAmount;
}
public Double getAmount() {
return amount;
}
}
现在比之前来讲，我们的策略模式更加灵活一点，但是策略模式也是有缺点的，就是当策略改变时，我们需要使用elseif去判断到底使用哪一个策略，哪怕使用简单工厂，也避免不了这一点。比如我们又添加一类会员，那么你需要去添加elseif。再比如我们的会员现在打九折了，那么你需要添加一个九折的策略，这没问题，我们对扩展开放，但是你需要修改elseif的分支，将会员的策略从八折替换为九折，这是简单工厂的诟病，在之前已经提到过，对修改开放。
在简单工厂中提出可以用注解来解决这个问题。在这里我们需要给注解加入属性上限和下限，用来表示策略生效的区间，用来解决总金额判断的问题。
首先我们做一个注解，这个注解是用来给策略添加的，当中可以设置它的上下限：
package com.calprice;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
//这是我们的有效区间注解，可以给策略添加有效区间的设置
@Target(ElementType.TYPE)//表示只能给类添加该注解
@Retention(RetentionPolicy.RUNTIME)//这个必须要将注解保留在运行时
public @interface TotalValidRegion {
//为了简单，我们让区间只支持整数
int max() default Integer.MAX_VALUE;
int min() default Integer.MIN_VALUE;
}
下面就可以在我们的各个策略类里去设置生效区间了，我们将策略类全部改成如下形式：
package com.calprice;
@TotalValidRegion(max=1000)//设置普通的在0-1000生效，以下类似，不再注释
class Common implements CalPrice{
public Double calPrice(Double originalPrice) {
return originalPrice;
}
}
@TotalValidRegion(min=1000,max=2000)
class Vip implements CalPrice{
public Double calPrice(Double originalPrice) {
return originalPrice * 0.8;
}
}
@TotalValidRegion(min=2000,max=3000)
class SuperVip implements CalPrice{
public Double calPrice(Double originalPrice) {
return originalPrice * 0.7;
}
}
@TotalValidRegion(min=3000)
class GoldVip implements CalPrice{
public Double calPrice(Double originalPrice) {
return originalPrice * 0.5;
}
}
下面要做的最重要的工作，就是处理注解。我们在策略工厂处理注解，这个类会变的比较复杂一点：
package com.calprice1;
import java.io.File;
import java.io.FileFilter;
import java.lang.annotation.Annotation;
import java.net.URISyntaxException;
import java.util.ArrayList;
import java.util.List;
//我们使用一个标准的简单工厂来改进一下策略模式
public class CalPriceFactory {
private static final String CAL_PRICE_PACKAGE = "com.calprice";//这里是一个常量，表示我们扫描策略的包，这是LZ的包名
private ClassLoader classLoader = getClass().getClassLoader();//我们加载策略时的类加载器，我们任何类运行时信息必须来自该类加载器
private List> calPriceList;//策略列表
//根据客户的总金额产生相应的策略
public CalPrice createCalPrice(Customer customer){
//在策略列表查找策略
for (Class extends CalPrice> clazz : calPriceList) {
TotalValidRegion validRegion = handleAnnotation(clazz);//获取该策略的注解
//判断金额是否在注解的区间
if (customer.getTotalAmount() > validRegion.min() && customer.getTotalAmount() < validRegion.max()) {
try {
//是的话我们返回一个当前策略的实例
return clazz.newInstance();
} catch (Exception e) {
throw new RuntimeException("策略获得失败");
}
}
}
throw new RuntimeException("策略获得失败");
}
//处理注解，我们传入一个策略类，返回它的注解
private TotalValidRegion handleAnnotation(Class extends CalPrice> clazz){
Annotation[] annotations = clazz.getDeclaredAnnotations();
if (annotations == null || annotations.length == 0) {
return null;
}
for (int i = 0; i < annotations.length; i++) {
if (annotations[i] instanceof TotalValidRegion) {
return (TotalValidRegion) annotations[i];
}
}
return null;
}
//单例
private CalPriceFactory(){
init();
}
//在工厂初始化时要初始化策略列表
private void init(){
calPriceList = new ArrayList>();
File[] resources = getResources();//获取到包下所有的class文件
Class calPriceClazz = null;
try {
calPriceClazz = (Class) classLoader.loadClass(CalPrice.class.getName());//使用相同的加载器加载策略接口
} catch (ClassNotFoundException e1) {
throw new RuntimeException("未找到策略接口");
}
for (int i = 0; i < resources.length; i++) {
try {
//载入包下的类
Class> clazz = classLoader.loadClass(CAL_PRICE_PACKAGE + "."+resources[i].getName().replace(".class", ""));
//判断是否是CalPrice的实现类并且不是CalPrice它本身，满足的话加入到策略列表
if (CalPrice.class.isAssignableFrom(clazz) && clazz != calPriceClazz) {
calPriceList.add((Class extends CalPrice>) clazz);
}
} catch (ClassNotFoundException e) {
e.printStackTrace();
}
}
}
//获取扫描的包下面所有的class文件
private File[] getResources(){
try {
File file = new File(classLoader.getResource(CAL_PRICE_PACKAGE.replace(".", "/")).toURI());
return file.listFiles(new FileFilter() {
public boolean accept(File pathname) {
if (pathname.getName().endsWith(".class")) {//我们只扫描class文件
return true;
}
return false;
}
});
} catch (URISyntaxException e) {
throw new RuntimeException("未找到策略资源");
}
}
public static CalPriceFactory getInstance(){
return CalPriceFactoryInstance.instance;
}
private static class CalPriceFactoryInstance{
private static CalPriceFactory instance = new CalPriceFactory();
}
}
上述便是改善后的简单工厂，虽然比刚开始的简单工厂复杂了很多，但是我们的收益是很明显的，现在我们随便加入一个策略，并设置好它的生效区间，策略工厂就可以帮我们自动找到适应的策略。。在这里再特别说明一点，我们的策略实现类最好放在一个包中，这样我们可以扫描特定的包，可以加快初始化速度。
有了这个基于注解的简单工厂，还需要稍微改变下客户类，因为客户类本来是调用的工厂的静态方法，现在我们将工厂做成了单例，所以应该改成如下形式。
calPrice = CalPriceFactory.getInstance().createCalPrice(this);
现在直接再调用客户端代码，会产生与之前一样的结果，说明我们的策略正确选择了。
我们已经使用简单工厂，注解，反射等技术将策略模式优化的非常完美了，我们可以随意新增策略，并且不需要修改原有的任何代码。
144
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
