实战|如何消除又臭又长的if...else判断更优雅的编程
最近在作代码重构，发现了不少代码的烂味道。其余的很少说，今天主要说说那些又臭又长的if...else要如何重构。java
在介绍更更优雅的编程以前，让咱们一块儿回顾一下，很差的if...else代码spring
1、又臭又长的if...else
废话很少说，先看看下面的代码。编程
public interface IPay {
void pay();
}
@Service
public class AliaPay implements IPay {
@Override
public void pay() {
System.out.println("===发起支付宝支付===");
}
}
@Service
public class WeixinPay implements IPay {
@Override
public void pay() {
System.out.println("===发起微信支付===");
}
}
@Service
public class JingDongPay implements IPay {
@Override
public void pay() {
System.out.println("===发起京东支付===");
}
}
@Service
public class PayService {
@Autowired
private AliaPay aliaPay;
@Autowired
private WeixinPay weixinPay;
@Autowired
private JingDongPay jingDongPay;
public void toPay(String code) {
if ("alia".equals(code)) {
aliaPay.pay();
} else if ("weixin".equals(code)) {
weixinPay.pay();
} else if ("jingdong".equals(code)) {
jingDongPay.pay();
} else {
System.out.println("找不到支付方式");
}
}
}
复制代码
PayService类的toPay方法主要是为了发起支付，根据不一样的code，决定调用用不一样的支付类（好比：aliaPay）的pay方法进行支付。设计模式
这段代码有什么问题呢？也许有些人就是这么干的。微信
试想一下，若是支付方式愈来愈多，好比：又加了百度支付、美团支付、银联支付等等，就须要改toPay方法的代码，增长新的else...if判断，判断多了就会致使逻辑愈来愈多？网络
很明显，这里违法了设计模式六大原则的：开闭原则 和 单一职责原则。 ❝开闭原则：对扩展开放，对修改关闭。就是说增长新功能要尽可能少改动已有代码。app
单一职责原则：顾名思义，要求逻辑尽可能单一，不要太复杂，便于复用。ide
那有什么办法能够解决这个问题呢？ 
post
2、使用注解
代码中之因此要用code判断使用哪一个支付类，是由于code和支付类没有一个绑定关系，若是绑定关系存在了，就能够不用判断了。性能
咱们先定义一个注解。
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface PayCode {
String value();
String name();
}
复制代码
而后在全部的支付类上都加上注解
@PayCode(value = "alia", name = "支付宝支付")
@Service
public class AliaPay implements IPay {
@Override
public void pay() {
System.out.println("===发起支付宝支付===");
}
}
@PayCode(value = "weixin", name = "微信支付")
@Service
public class WeixinPay implements IPay {
@Override
public void pay() {
System.out.println("===发起微信支付===");
}
}
@PayCode(value = "jingdong", name = "京东支付")
@Service
public class JingDongPay implements IPay {
@Override
public void pay() {
System.out.println("===发起京东支付===");
}
}
复制代码
而后增长最关键的类：
@Service
public class PayService2 implements ApplicationListener<ContextRefreshedEvent> {
private static Map<String, IPay> payMap = null;
@Override
public void onApplicationEvent(ContextRefreshedEvent contextRefreshedEvent) {
ApplicationContext applicationContext = contextRefreshedEvent.getApplicationContext();
Map<String, Object> beansWithAnnotation = applicationContext.getBeansWithAnnotation(PayCode.class);
if (beansWithAnnotation != null) {
payMap = new HashMap<>();
beansWithAnnotation.forEach((key, value) -> {
String bizType = value.getClass().getAnnotation(PayCode.class).value();
payMap.put(bizType, (IPay) value);
});
}
}
public void pay(String code) {
payMap.get(code).pay();
}
}
复制代码
PayService2类实现了ApplicationListener接口，这样在onApplicationEvent方法中，就能够拿到ApplicationContext的实例。咱们再获取打了PayCode注解的类，放到一个map中，map中的key就是PayCode注解中定义的value，跟code参数一致，value是支付类的实例。
这样，每次就能够每次直接经过code获取支付类实例，而不用if...else判断了。若是要加新的支付方法，只需在支付类上面打上PayCode注解定义一个新的code便可。
注意：这种方式的code能够没有业务含义，能够是纯数字，只有不重复就行。
3、动态拼接名称
再看看这种方法，主要针对code是有业务含义的场景。
@Service
public class PayService3 implements ApplicationContextAware {
private ApplicationContext applicationContext;
private static final String SUFFIX = "Pay";
@Override
public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
this.applicationContext = applicationContext;
}
public void toPay(String payCode) {
((IPay) applicationContext.getBean(getBeanName(payCode))).pay();
}
public String getBeanName(String payCode) {
return payCode + SUFFIX;
}
}
复制代码
咱们能够看到，支付类bean的名称是由code和后缀拼接而成，好比：aliaPay、weixinPay和jingDongPay。这就要求支付类取名的时候要特别注意，前面的一段要和code保持一致。调用的支付类的实例是直接从ApplicationContext实例中获取的，默认状况下bean是单例的，放在内存的一个map中，因此不会有性能问题。
特别说明一下，这种方法实现了ApplicationContextAware接口跟上面的ApplicationListener接口不同，是想告诉你们获取ApplicationContext实例的方法不仅一种。
4、模板方法判断
固然除了上面介绍的两种方法以外，spring的源码实现中也告诉咱们另一种思路，解决if...else问题。
咱们先一块儿看看spring AOP的部分源码，看一下DefaultAdvisorAdapterRegistry的wrap方法
public Advisor wrap(Object adviceObject) throws UnknownAdviceTypeException {
if (adviceObject instanceof Advisor) {
return (Advisor) adviceObject;
}
if (!(adviceObject instanceof Advice)) {
throw new UnknownAdviceTypeException(adviceObject);
}
Advice advice = (Advice) adviceObject;
if (advice instanceof MethodInterceptor) {
// So well-known it doesn't even need an adapter.
return new DefaultPointcutAdvisor(advice);
}
for (AdvisorAdapter adapter : this.adapters) {
// Check that it is supported.
if (adapter.supportsAdvice(advice)) {
return new DefaultPointcutAdvisor(advice);
}
}
throw new UnknownAdviceTypeException(advice);
}
复制代码
重点看看supportAdvice方法，有三个类实现了这个方法。咱们随便抽一个类看看
class AfterReturningAdviceAdapter implements AdvisorAdapter, Serializable {
@Override
public boolean supportsAdvice(Advice advice) {
return (advice instanceof AfterReturningAdvice);
}
@Override
public MethodInterceptor getInterceptor(Advisor advisor) {
AfterReturningAdvice advice = (AfterReturningAdvice) advisor.getAdvice();
return new AfterReturningAdviceInterceptor(advice);
}
}
复制代码
该类的supportsAdvice方法很是简单，只是判断了一下advice的类型是否是AfterReturningAdvice。
咱们看到这里应该有所启发。
其实，咱们能够这样作，定义一个接口或者抽象类，里面有个support方法判断参数传的code是否本身能够处理，若是能够处理则走支付逻辑。
public interface IPay {
boolean support(String code);
void pay();
}
@Service
public class AliaPay implements IPay {
@Override
public boolean support(String code) {
return "alia".equals(code);
}
@Override
public void pay() {
System.out.println("===发起支付宝支付===");
}
}
@Service
public class WeixinPay implements IPay {
@Override
public boolean support(String code) {
return "weixin".equals(code);
}
@Override
public void pay() {
System.out.println("===发起微信支付===");
}
}
@Service
public class JingDongPay implements IPay {
@Override
public boolean support(String code) {
return "jingdong".equals(code);
}
@Override
public void pay() {
System.out.println("===发起京东支付===");
}
}
复制代码
每一个支付类都有一个support方法，判断传过来的code是否和本身定义的相等。
@Service
public class PayService4 implements ApplicationContextAware, InitializingBean {
private ApplicationContext applicationContext;
private List<IPay> payList = null;
@Override
public void afterPropertiesSet() throws Exception {
if (payList == null) {
payList = new ArrayList<>();
Map<String, IPay> beansOfType = applicationContext.getBeansOfType(IPay.class);
beansOfType.forEach((key, value) -> payList.add(value));
}
}
@Override
public void setApplicationContext(ApplicationContext applicationContext) throws BeansException {
this.applicationContext = applicationContext;
}
public void toPay(String code) {
for (IPay iPay : payList) {
if (iPay.support(code)) {
iPay.pay();
}
}
}
}
复制代码
这段代码中先把实现了IPay接口的支付类实例初始化到一个list集合中，返回在调用支付接口时循环遍历这个list集合，若是code跟本身定义的同样，则调用当前的支付类实例的pay方法。
5、其余的消除if...else的方法
固然实际项目开发中使用if...else判断的场景很是多，上面只是其中几种场景。下面再列举一下，其余常见的场景。
1.根据不一样的数字返回不一样的字符串
public String getMessage(int code) {
if (code == 1) {
return "成功";
} else if (code == -1) {
return "失败";
} else if (code == -2) {
return "网络超时";
} else if (code == -3) {
return "参数错误";
}
throw new RuntimeException("code错误");
}
复制代码
其实，这种判断没有必要，用一个枚举就能够搞定。
public enum MessageEnum {
SUCCESS(1, "成功"),
FAIL(-1, "失败"),
TIME_OUT(-2, "网络超时"),
PARAM_ERROR(-3, "参数错误");
private int code;
private String message;
MessageEnum(int code, String message) {
this.code = code;
this.message = message;
}
public int getCode() {
return this.code;
}
public String getMessage() {
return this.message;
}
public static MessageEnum getMessageEnum(int code) {
return Arrays.stream(MessageEnum.values()).filter(x -> x.code == code).findFirst().orElse(null);
}
}
复制代码
再把调用方法稍微调整一下
public String getMessage(int code) {
MessageEnum messageEnum = MessageEnum.getMessageEnum(code);
return messageEnum.getMessage();
}
复制代码
完美。
2.集合中的判断
上面的枚举MessageEnum中的getMessageEnum方法，若是不用java8的语法的话，可能要这样写
public static MessageEnum getMessageEnum(int code) {
for (MessageEnum messageEnum : MessageEnum.values()) {
if (code == messageEnum.code) {
return messageEnum;
}
}
return null;
}
复制代码
对于集合中过滤数据，或者查找方法，java8有更简单的方法消除if...else判断。
public static MessageEnum getMessageEnum(int code) {
return Arrays.stream(MessageEnum.values()).filter(x -> x.code == code).findFirst().orElse(null);
}
复制代码
3.简单的判断
其实有些简单的if...else彻底没有必要写，能够用三目运算符代替，好比这种状况：
public String getMessage2(int code) {
if(code == 1) {
return "成功";
}
return "失败";
}
复制代码
改为三目运算符：
public String getMessage2(int code) {
return code == 1 ? "成功" : "失败";
}
复制代码
修改以后代码更简洁一些。
4.判断是否为null
java中自从有了null以后，不少地方都要判断实例是否为null，否则可能会出现NPE的异常。
public String getMessage2(int code) {
return code == 1 ? "成功" : "失败";
}
public String getMessage3(int code) {
Test test = null;
return test.getMessage2(1);
}
复制代码
这里若是不判断异常的话，就会出现NPE异常。咱们只能老老实实加上判断。
public String getMessage3(int code) {
Test test = null;
if (test != null) {
return test.getMessage2(1);
}
return null;
}
复制代码
有没有其余更优雅的处理方式呢？
public String getMessage3(int code) {
Test test = null;
Optional<Test> testOptional = Optional.of(test);
return testOptional.isPresent() ? testOptional.get().getMessage2(1) : null;
}
复制代码
答案是使用Optional
固然，还有不少其余的场景能够优化if...else，我再这里就不一一介绍了，感兴趣的朋友能够给我留言，一块儿探讨和研究一下。
- 1. 消灭又臭又长的if-else
- 2. 优雅代码之消除if-else判断
- 3. java如何消除太多的if else判断？
- 4. 如何让 if/else 更优雅？
- 5. 消除“if...else”实战
- 6. 消除if...else实战
- 7. if，else判断
- 8. JavaScript复杂判断(if else / switch)的更优雅写法优化冗余
- 9. 支付业务实战消除if else
- 10. bash编程之if……else条件判断
- 更多相关文章...
- • Swift if...else if...else 语句 - Swift 教程
- • C# 判断 - C#教程
- • Docker容器实战(八) - 漫谈 Kubernetes 的本质
- • Docker容器实战(七) - 容器眼光下的文件系统
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 融合阿里云，牛客助您找到心仪好工作
- 2. 解决jdbc(jdbctemplate)在测试类时不报错在TomCatb部署后报错
- 3. 解决PyCharm GoLand IntelliJ 等 JetBrains 系列 IDE无法输入中文
- 4. vue+ant design中关于图片请求不显示的问题。
- 5. insufficient memory && Native memory allocation (malloc) failed
- 6. 解决IDEA用Maven创建的Web工程不能创建Java Class文件的问题
- 7. [已解决] Error: Cannot download ‘https://start.spring.io/starter.zip?
- 8. 在idea让java文件夹正常使用
- 9. Eclipse启动提示“subversive connector discovery”
- 10. 帅某-技巧-快速转帖博主文章（article_content）