Java使用策略模式代替多个if else，避免代码糅合在一起，降低维护成本和提高阅读观赏性，遵循代码解耦思想

前言平常开发时总是避免不了多个if else判断执行不同的业务逻辑通常写法基本都是糅合在一起显得代码又臭又长维护成本很高也不美观修改部分业务逻辑整体业务模块都要重新测一遍大大的提高了工作量。话不多说代码开整需求前端传一个userFrom类型此类型为1:入驻码,2:引流码,3:自然流量,:4医生推荐,5:引流人推荐,后台需求需要根据不同类型执行相应的业务逻辑每个类型的业务逻辑都不一样。1.新手写法public int bindDoctorw(BindDoctorRequest dindDoctorRequest) { if(dindDoctorRequest.getUserFrom()1){ //执行业务代码 }else if(dindDoctorRequest.getUserFrom()2){ //执行业务代码 }else if(dindDoctorRequest.getUserFrom()3){ //执行业务代码 }else if(dindDoctorRequest.getUserFrom()4){ //执行业务代码 }else if(dindDoctorRequest.getUserFrom()5){ //执行业务代码 } return 0; }具体业务代码就不写了要是都糅合在一起自己想象一下bindDoctorw方法有多长虽然看起来流程步骤很清晰但是维护成本变高了所以这种方法是不可取的要是你是干外包的项目请移步外包的要求还那么多这样就行了。2.代码解耦拆分写法public int bindDoctorw(BindDoctorRequest dindDoctorRequest) { if(dindDoctorRequest.getUserFrom()1){ //执行业务代码 UserFrom1(dindDoctorRequest); }else if(dindDoctorRequest.getUserFrom()2){ //执行业务代码 UserFrom2(dindDoctorRequest); }else if(dindDoctorRequest.getUserFrom()3){ //执行业务代码 UserFrom3(dindDoctorRequest); }else if(dindDoctorRequest.getUserFrom()4){ //执行业务代码 UserFrom4(dindDoctorRequest); }else if(dindDoctorRequest.getUserFrom()5){ //执行业务代码 UserFrom5(dindDoctorRequest); } } public int UserFrom1(BindDoctorRequest dindDoctorRequest) { } public int UserFrom2(BindDoctorRequest dindDoctorRequest) { } public int UserFrom3(BindDoctorRequest dindDoctorRequest) { } public int UserFrom4(BindDoctorRequest dindDoctorRequest) { } public int UserFrom5(BindDoctorRequest dindDoctorRequest) { }或者这种写法public int bindDoctorw(BindDoctorRequest dindDoctorRequest) { switch (dindDoctorRequest.getUserFrom()){ case 1: //执行业务代码 UserFrom1(); break; case 2: //执行业务代码 UserFrom2(); break; case 3: //执行业务代码 UserFrom3(); break; case 4: //执行业务代码 UserFrom4(); break; case 5: //执行业务代码 UserFrom5(); break; } } public int UserFrom1(BindDoctorRequest dindDoctorRequest) { } public int UserFrom2(BindDoctorRequest dindDoctorRequest) { } public int UserFrom3(BindDoctorRequest dindDoctorRequest) { } public int UserFrom4(BindDoctorRequest dindDoctorRequest) { } public int UserFrom5(BindDoctorRequest dindDoctorRequest) { }这种看起来要比第一种美观多了把对应的业务逻辑解耦拆分每次业务变动只需要变动对应类型方法的业务就行维护成本大大降低但是有没有更好的写法呢那肯定是有的这里就要讲到策略模式写法3.策略模式写法策略模式是一种行为设计模式它允许在运行时选择算法或行为。核心思想将算法的选择和使用算法的上下文分离。主要组成部分策略接口定义了一个或多个算法的方法。具体策略类实现了策略接口中的方法每个类代表一个具体的算法。上下文类持有一个策略对象的引用并在需要时调用该策略对象的方法。工作原理客户端根据需要选择一个具体的策略类并实例化它。将实例化的策略对象传递给上下文类。上下文类使用传递进来的策略对象来执行相应的算法。优点灵活性算法可以独立于使用它的客户端而变化。可扩展性添加新算法时无需修改现有代码。可维护性每个算法都被封装在自己的类中使得代码更加清晰和易于维护。应用场景当存在多个算法并且这些算法需要在运行时根据条件进行切换时。当一个算法有多种实现方式并且这些实现方式需要在不同情况下被选择时。下面是具体实现方法3.1 提供一个service实现类用于外部controller调用Override public int bindDoctor(BindDoctorRequest dindDoctorRequest) { UserFromImplementsStrategy entryStrategy FromTypeStrategyFactory.getStrategy(dindDoctorRequest.getUserFrom()); return entryStrategy.execute(dindDoctorRequest); }3.2 定义策略接口/** * 用户来源策略 */ public interface UserFromImplementsStrategy { int execute(BindDoctorRequest request); }3.3 实现具体的策略类/** * 医生推荐策略处理逻辑 */ public class DoctorReferralStrategy implements UserFromImplementsStrategy { Override public int execute(BindDoctorRequest request) { //执行具体的业务逻辑 return Constants.SUCCESS_CODE; }/** * 入驻码策略处理逻辑 */ public class EntryCodeStrategy implements UserFromImplementsStrategy { Override public int execute(BindDoctorRequest request) { //执行具体的业务逻辑 return Constants.SUCCESS_CODE; }/** * 引流码策略处理逻辑 */ public class LeadCodeStrategy implements UserFromImplementsStrategy { Override public int execute(BindDoctorRequest request) { //执行具体的业务逻辑 return Constants.SUCCESS_CODE; }/** * 引流人推荐策略处理逻辑 */ public class LeadReferrerStrategy implements UserFromImplementsStrategy { Override public int execute(BindDoctorRequest request) { //执行具体的业务逻辑 return Constants.SUCCESS_CODE; } }public class NaturalFlowStrategy implements UserFromImplementsStrategy { Override public int execute(BindDoctorRequest request) { //执行具体的业务逻辑 return Constants.SUCCESS_CODE; } }/** * 医生推荐策略处理逻辑 */ public class NutritionistStrategy implements UserFromImplementsStrategy { Override public int execute(BindDoctorRequest request) { //执行具体的业务逻辑 return Constants.SUCCESS_CODE; } }3.4 创建策略工厂public class FromTypeStrategyFactory { public static UserFromImplementsStrategy getStrategy(Long userfromType) { if (userfromType UserFromEnum.ENTER_CODE_TYPE.getCode()) { return new EntryCodeStrategy(); } else if (userfromType UserFromEnum.DRIVE_CODE_TYPE.getCode()) { return new LeadCodeStrategy(); } else if (userfromType UserFromEnum.DRIVE_CODE_RECOMMEND_TYPE.getCode()) { return new NaturalFlowStrategy(); } else if (userfromType UserFromEnum.DOCTOR_CODE_RECOMMEND_TYPE.getCode()) { return new DoctorReferralStrategy(); } else if (userfromType UserFromEnum.DOCTOR_CODE_TYPE.getCode()) { return new LeadReferrerStrategy(); }else if (userfromType UserFromEnum.NUTRITIONIST_CODE_TYPE.getCode()) { return new NutritionistStrategy(); } throw new BaseException(Unknown code type: userfromType); } } public enum UserFromEnum { //1入驻码2引流码3自然流量4医生推荐5引流人推荐6营养师列表绑定 ENTER_CODE_TYPE(1L,入驻码), DRIVE_CODE_TYPE(2L,引流码), DRIVE_CODE_RECOMMEND_TYPE(3L,自然流量), DOCTOR_CODE_RECOMMEND_TYPE(4L,医生推荐), DOCTOR_CODE_TYPE(5L,引流人推荐), NUTRITIONIST_CODE_TYPE(6L,营养师列表绑定), ; private final Long code; private final String message; UserFromEnum(Long code, String message) { this.code code; this.message message; } public Long getCode() {return code;} public String getMessage() {return message;} }乍一看代码变多了实际确实是变多了但是每一个方法都有自己的实现类业务逻辑拆分开各自维护互不干扰其实正常来讲第二种写法就已经够了但是为了显得自己突出一点就这么整每个方法各有各的优点和缺点就看写的人怎么想了。程序员的代码是各有各的风格写的不好不要乱喷只为了给后来人一点借鉴我们都是站在巨人的肩膀上前进希望能帮到你们喜欢的点个收藏关注吧如果你有什么需求无法解决也可以私聊我我有空也可以给你写例子或者给你一个方向比你慢慢摸索的强。