java设计模式—策略模式

一朵纯洁的小白花

已于 2022-02-08 15:19:55 修改

阅读量404

点赞数 2

分类专栏：设计模式 java 文章标签： java 策略模式开发语言

于 2022-02-08 15:08:54 首次发布

本文链接：https://blog.csdn.net/TurboAnho/article/details/122823773

版权

java 同时被 2 个专栏收录

32 篇文章 0 订阅

订阅专栏

设计模式

3 篇文章 0 订阅

订阅专栏

策略模式：定义一系列算法类，将每一个算法封装起来，并让它们可以相互替换。策略模式让算法独立于使用它的客户而变化。它也被成为政策模式，是一种行为型模式。

介绍

意图：定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。

主要解决：在有多种算法相似的情况下，使用 if…else 所带来的复杂和难以维护。

何时使用：一个系统有许多许多类，而区分它们的只是他们直接的行为。

如何解决：将这些算法封装成一个一个的类，任意地替换。

关键代码：实现同一个接口。

优点：1、算法可以自由切换。 2、避免使用多重条件判断。 3、扩展性良好。

缺点： 1、策略类会增多。 2、所有策略类都需要对外暴露。

注意事项：如果一个系统的策略多于四个，就需要考虑使用混合模式，解决策略类膨胀的问题。

----------------------------------------------

解决问题：太多if-else影响可读性和可维护性

对于业务开发来说，业务逻辑的复杂是必然的，随着业务发展，需求只会越来越复杂，为了考虑到各种各样的情况，代码中不可避免的会出现很多if-else。

一旦代码中if-else过多，就会大大的影响其可读性和可维护性。

在这里插入图片描述

消除if-else，其中比较典型的并且使用广泛的就是借助策略模式和工厂模式，准确的说是利用这两个设计模式的思想，彻底消灭代码中的if-else。

举例外卖平台需求

本文，就结合这两种设计模式，介绍如何消除if-else，并且，还会介绍如何和Spring框架结合，这样读者看完本文之后就可以立即应用到自己的项目中。

本文涉及到一些代码，但是作者尽量用通俗的例子和伪代码等形式使内容不那么枯燥。

恶心的if-else

假设我们要做一个外卖平台，有这样的需求：

1、外卖平台上的某家店铺为了促销，设置了多种会员优惠，其中包含超级会员折扣8折、普通会员折扣9折和普通用户没有折扣三种。

2、希望用户在付款的时候，根据用户的会员等级，就可以知道用户符合哪种折扣策略，进而进行打折，计算出应付金额。

3、随着业务发展，新的需求要求专属会员要在店铺下单金额大于30元的时候才可以享受优惠。

4、接着，又有一个变态的需求，如果用户的超级会员已经到期了，并且到期时间在一周内，那么就对用户的单笔订单按照超级会员进行折扣，并在收银台进行强提醒，引导用户再次开通会员，而且折扣只进行一次。

那么，我们可以看到以下伪代码：

public BigDecimal calPrice(BigDecimal orderPrice, String buyerType) {

    if (用户是专属会员) {
        if (订单金额大于30元) {
            returen 7折价格;
        }
    }

    if (用户是超级会员) {
        return 8折价格;
    }

    if (用户是普通会员) {
        if(该用户超级会员刚过期并且尚未使用过临时折扣){
            临时折扣使用次数更新();
            returen 8折价格;
        }
        return 9折价格;
    }
    return 原价;
}

以上，就是对于这个需求的一段价格计算逻辑，使用伪代码都这么复杂，如果是真的写代码，那复杂度可想而知。

这样的代码中，有很多if-else，并且还有很多的if-else的嵌套，无论是可读性还是可维护性都非常低。

那么，如何改善呢？

引入策略模式

接下来，我们尝试引入策略模式来提升代码的可维护性和可读性。

首先，定义一个接口：

/**
 * @author mhcoding
 */
public interface UserPayService {

    /**
     * 计算应付价格
     */
    public BigDecimal quote(BigDecimal orderPrice);
}

接着定义几个策略类：

/**
 * @author mhcoding
 */
public class ParticularlyVipPayService implements UserPayService {

    @Override
    public BigDecimal quote(BigDecimal orderPrice) {
         if (消费金额大于30元) {
            return 7折价格;
        }
    }
}

public class SuperVipPayService implements UserPayService {

    @Override
    public BigDecimal quote(BigDecimal orderPrice) {
        return 8折价格;
    }
}

public class VipPayService implements UserPayService {

    @Override
    public BigDecimal quote(BigDecimal orderPrice) {
        if(该用户超级会员刚过期并且尚未使用过临时折扣){
            临时折扣使用次数更新();
            returen 8折价格;
        }
        return 9折价格;
    }
}

引入了策略之后，我们可以按照如下方式进行价格计算：

/**
 * @author mhcoding
 */
public class Test {

    public static void main(String[] args) {
        UserPayService strategy = new VipPayService();
        BigDecimal quote = strategy.quote(300);
        System.out.println("普通会员商品的最终价格为：" + quote.doubleValue());

        strategy = new SuperVipPayService();
        quote = strategy.quote(300);
        System.out.println("超级会员商品的最终价格为：" + quote.doubleValue());
    }
}

以上，就是一个例子，可以在代码中new出不同的会员的策略类，然后执行对应的计算价格的方法。

但是，真正在代码中使用，比如在一个web项目中使用，上面这个Demo根本没办法直接用

首先，在web项目中，上面我们创建出来的这些策略类都是被Spring托管的，我们不会自己去new一个实例出来。

其次，在web项目中，如果真要计算价格，也是要事先知道用户的会员等级，比如从数据库中查出会员等级，然后根据等级获取不同的策略类执行计算价格方法。

那么，web项目中真正的计算价格的话，伪代码应该是这样的：

/**
 * @author mhcoding
 */
public BigDecimal calPrice(BigDecimal orderPrice,User user) {

     String vipType = user.getVipType();

     if (vipType == 专属会员) {
        //伪代码：从Spring中获取超级会员的策略对象
        UserPayService strategy = Spring.getBean(ParticularlyVipPayService.class);
        return strategy.quote(orderPrice);
     }

     if (vipType == 超级会员) {
        UserPayService strategy = Spring.getBean(SuperVipPayService.class);
        return strategy.quote(orderPrice);
     }

     if (vipType == 普通会员) {
        UserPayService strategy = Spring.getBean(VipPayService.class);
        return strategy.quote(orderPrice);
     }
     return 原价;
}

通过以上代码，我们发现代码可维护性和可读性好像是好了一些，但是好像并没有减少if-else啊。

策略模式的使用上，还是有一个比较大的缺点的：

客户端必须知道所有的策略类，并自行决定使用哪一个策略类。这就意味着客户端必须理解这些算法的区别，以便适时选择恰当的算法类。

借助Spring和工厂模式解决策略模式存在的问题

为了方便我们从Spring中获取UserPayService的各个策略类，我们创建一个工厂类：

/**
 * @author mhcoding
 */
public class UserPayServiceStrategyFactory {

    private static Map<String,UserPayService> services = new ConcurrentHashMap<String,UserPayService>();

    public  static UserPayService getByUserType(String type){
        return services.get(type);
    }

    public static void register(String userType,UserPayService userPayService){
        Assert.notNull(userType,"userType can't be null");
        services.put(userType,userPayService);
    }
}

这个UserPayServiceStrategyFactory中定义了一个Map，用来保存所有的策略类的实例，并提供一个getByUserType方法，可以根据类型直接获取对应的类的实例。还有一个register方法，这个后面再讲。

有了这个工厂类之后，计算价格的代码即可得到大大的优化：

/**
 * @author mhcoding
 */
public BigDecimal calPrice(BigDecimal orderPrice,User user) {

     String vipType = user.getVipType();
     UserPayService strategy = UserPayServiceStrategyFactory.getByUserType(vipType);
     return strategy.quote(orderPrice);
}

以上代码中，不再需要if-else了，拿到用户的vip类型之后，直接通过工厂的getByUserType方法直接调用就可以了。

通过策略+工厂，我们的代码很大程度的优化了，大大提升了可读性和可维护性。

但是，上面还遗留了一个问题，那就是UserPayServiceStrategyFactory中用来保存所有的策略类的实例的Map是如何被初始化的？各个策略的实例对象如何塞进去的呢？

Spring Bean的注册

还记得我们前面定义的UserPayServiceStrategyFactory中提供了的register方法吗？他就是用来注册策略服务的。

接下来，我们就想办法调用register方法，把Spring通过IOC创建出来的Bean注册进去就行了。

这种需求，可以借用Spring种提供的InitializingBean接口，这个接口为Bean提供了属性初始化后的处理方法，它只包括afterPropertiesSet方法，凡是继承该接口的类，在bean的属性初始化后都会执行该方法。

那么，我们将前面的各个策略类稍作改造即可：

/**
 * @author mhcoding
 */
@Service
public class ParticularlyVipPayService implements UserPayService,InitializingBean {

    @Override
    public BigDecimal quote(BigDecimal orderPrice) {
         if (消费金额大于30元) {
            return 7折价格;
        }
    }

    @Override
    public void afterPropertiesSet() throws Exception {
        UserPayServiceStrategyFactory.register("ParticularlyVip",this);
    }
}

@Service
public class SuperVipPayService implements UserPayService ,InitializingBean{

    @Override
    public BigDecimal quote(BigDecimal orderPrice) {
        return 8折价格;
    }

    @Override
    public void afterPropertiesSet() throws Exception {
        UserPayServiceStrategyFactory.register("SuperVip",this);
    }
}

@Service  
public class VipPayService implements UserPayService,InitializingBean {

    @Override
    public BigDecimal quote(BigDecimal orderPrice) {
        if(该用户超级会员刚过期并且尚未使用过临时折扣){
            临时折扣使用次数更新();
            returen 8折价格;
        }
        return 9折价格;
    }

    @Override
    public void afterPropertiesSet() throws Exception {
        UserPayServiceStrategyFactory.register("Vip",this);
    }
}

只需要每一个策略服务的实现类都实现InitializingBean接口，并实现其afterPropertiesSet方法，在这个方法中调用UserPayServiceStrategyFactory.register即可。

这样，在Spring初始化的时候，当创建VipPayService、SuperVipPayService和ParticularlyVipPayService的时候，会在Bean的属性初始化之后，把这个Bean注册到UserPayServiceStrategyFactory中。

以上代码，其实还是有一些重复代码的，这里面还可以引入模板方法模式进一步精简，这里就不展开了。

还有就是，UserPayServiceStrategyFactory.register调用的时候，第一个参数需要传一个字符串，这里的话其实也可以优化掉。比如使用枚举，或者在每个策略类中自定义一个getUserType方法，各自实现即可。

总结

本文，我们通过策略模式、工厂模式以及Spring的InitializingBean，提升了代码的可读性以及可维护性，彻底消灭了一坨if-else。

以上的还不是纯策略模式，纯策略模式具有Context对象

可参考如下示例：

//步骤 1   创建一个接口Strategy.java

public interface Strategy {

    int doOperation(int num1, int num2);

}

//步骤 2   
//创建实现接口的实体类OperationAdd.java
public class OperationAdd implements Strategy {

    @Override
    public int doOperation(int num1, int num2) {
        return num1 + num2;
    }

}
//创建实现接口的实体类OperationSubstract.java
public class OperationSubstract implements Strategy {

    @Override
    public int doOperation(int num1, int num2) {
        return num1 - num2;
    }

}

//创建实现接口的实体类OperationMultiply.java
public class OperationMultiply implements Strategy {

    @Override
    public int doOperation(int num1, int num2) {
        return num1 * num2;
    }

}
//步骤 3  
//创建 Context 类Context.java
public class Context {

    private Strategy strategy;

    public Context(Strategy strategy){
        this.strategy = strategy;
    }

    public int executeStrategy(int num1, int num2){
        return strategy.doOperation(num1, num2);
    }

}
//步骤 4
//使用 Context 来查看当它改变策略 Strategy 时的行为变化StatePatternDemo.java
public class StrategyPatternDemo {

    public static void main(String[] args) {
        Context context = new Context(new OperationAdd());
        System.out.println("10 + 5 = " + context.executeStrategy(10, 5));

        context = new Context(new OperationSubstract());
        System.out.println("10 - 5 = " + context.executeStrategy(10, 5));

        context = new Context(new OperationMultiply());
        System.out.println("10 * 5 = " + context.executeStrategy(10, 5));
    }

}
//步骤 5验证输出
// 10 + 5 = 15
// 10 - 5 = 5
// 10 * 5 = 50

一朵纯洁的小白花

关注

2
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
java设计模式—策略模式

策略模式：定义一系列算法类，将每一个算法封装起来，并让它们可以相互替换。策略模式让算法独立于使用它的客户而变化。它也被成为政策模式，是一种行为型模式。介绍意图：定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。主要解决：在有多种算法相似的情况下，使用 if…else 所带来的复杂和难以维护。何时使用：一个系统有许多许多类，而区分它们的只是他们直接的行为。如何解决：将这些算法封装成一个一个的类，任意地替换。关键代码：实现同一个接口。优点：1、算法可以自由切换。 .
复制链接

扫一扫