定义:策略模式定义了一系列的算法,并将每一个算法封装起来,而且使它们还可以相互替换。策略模式让算法独立于使用它的客户而独立变化。
如果我们往一个方法当中插入随便一段独立的(算法)代码,就是策略模式。
比如,原来的类是这个样子:
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<Class<? extends CalPrice>> 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<Class<? extends CalPrice>>();
File[] resources = getResources();//获取到包下所有的class文件
Class<CalPrice> calPriceClazz = null;
try {
calPriceClazz = (Class<CalPrice>) 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);
现在直接再调用客户端代码,会产生与之前一样的结果,说明我们的策略正确选择了。
我们已经使用简单工厂,注解,反射等技术将策略模式优化的非常完美了,我们可以随意新增策略,并且不需要修改原有的任何代码。
共同学习,写下你的评论
评论加载中...
作者其他优质文章