种子汤唯梁朝伟做视频网站,100个创意商标名字,站长之家网址查询,做游戏出租的网站好对于业务开发来说#xff0c;业务逻辑的复杂是必然的#xff0c;随着业务发展#xff0c;需求只会越来越复杂#xff0c;为了考虑到各种各样的情况#xff0c;代码中不可避免的会出现很多if-else。一旦代码中if-else过多#xff0c;就会大大的影响其可读性和可维护性。…对于业务开发来说业务逻辑的复杂是必然的随着业务发展需求只会越来越复杂为了考虑到各种各样的情况代码中不可避免的会出现很多if-else。一旦代码中if-else过多就会大大的影响其可读性和可维护性。首先可读性不言而喻过多的if-else代码和嵌套会使阅读代码的人很难理解到底是什么意思。尤其是那些没有注释的代码。其次是可维护性因为if-else特别多想要新加一个分支的时候就会很难添加极其容易影响到其他的分支。笔者曾经看到过一个支付的核心应用这个应用支持了很多业务的线上支付功能但是每个业务都有很多定制的需求所以很多核心的代码中都有一大坨if-else。每个新业务需要定制的时候都把自己的if放到整个方法的最前面以保证自己的逻辑可以正常执行。这种做法后果可想而知。其实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 {Overridepublic BigDecimal quote(BigDecimal orderPrice) {if (消费金额大于30元) {return 7折价格;}}
}public class SuperVipPayService implements UserPayService {Overridepublic BigDecimal quote(BigDecimal orderPrice) {return 8折价格;}
}public class VipPayService implements UserPayService {Overridepublic 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啊。其实在之前的《如何给女朋友解释什么是策略模式》一文中我们介绍了很多策略模式的优点。但是策略模式的使用上还是有一个比较大的缺点的客户端必须知道所有的策略类并自行决定使用哪一个策略类。这就意味着客户端必须理解这些算法的区别以便适时选择恰当的算法类。也就是说虽然在计算价格的时候没有if-else了但是选择具体的策略的时候还是不可避免的还是要有一些if-else。另外上面的伪代码中从Spring中获取会员的策略对象我们是伪代码实现的那么代码到底该如何获取对应的Bean呢接下来我们看如何借助Spring和工厂模式解决上面这些问题。工厂模式为了方便我们从Spring中获取UserPayService的各个策略类我们创建一个工厂类/*** author mhcoding*/
public class UserPayServiceStrategyFactory {private static MapString,UserPayService services new ConcurrentHashMapString,UserPayService();public static UserPayService getByUserType(String type){return services.get(type);}public static void register(String userType,UserPayService userPayService){Assert.notNull(userType,userType cant 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 {Overridepublic BigDecimal quote(BigDecimal orderPrice) {if (消费金额大于30元) {return 7折价格;}}Overridepublic void afterPropertiesSet() throws Exception {UserPayServiceStrategyFactory.register(ParticularlyVip,this);}
}Service
public class SuperVipPayService implements UserPayService ,InitializingBean{Overridepublic BigDecimal quote(BigDecimal orderPrice) {return 8折价格;}Overridepublic void afterPropertiesSet() throws Exception {UserPayServiceStrategyFactory.register(SuperVip,this);}
}Service
public class VipPayService implements UserPayService,InitializingBean {Overridepublic BigDecimal quote(BigDecimal orderPrice) {if(该用户超级会员刚过期并且尚未使用过临时折扣){临时折扣使用次数更新();returen 8折价格;}return 9折价格;}Overridepublic 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角色在这里面是没有的没有Context也就没有用到组合的方式而是使用工厂代替了。另外这里面的UserPayServiceStrategyFactory其实只是维护了一个Map并提供了register和get方法而已而工厂模式其实是帮忙创建对象的这里并没有用到。所以读者不必纠结于到底是不是真的用了策略模式和工厂模式。而且这里面也再扩展一句所谓的GOF 23种设计模式无论从哪本书或者哪个博客看都是简单的代码示例但是我们日常开发很多都是基于Spring等框架的根本没办法直接用的。所以对于设计模式的学习重要的是学习其思想而不是代码实现如果读者们感兴趣后续可以出更多的设计模式和Spring等框架结合使用的最佳实践。希望通过这样的文章读者可以真正的在代码中使用上设计模式。作者漫话编程链接https://juejin.im/post/5dad23685188251d2c4ea2b6来源掘金
