背景
由于目前工作岗位的原因,项目还是09年建立的,历史遗留问题也比较多,加上开发规范并不是很完善,项目中有的单个方法达到成百上千行,if-else更是连续写十几个也不累。
作为强迫症真的受不了,另一方面,代码的可读性以及可扩展性大大降低。在接下来的文章中,将结合不同的场景介绍几种优化if-else的常见方案。
一、巧用三目运算符
这种场景很常见,在开发过程中,碰到if-else的时候,可以想一下,是不是可以用三目运算符来替换?当然可以,不然我写文章干嘛,哈哈哈
//优化前
public static void before(boolean condition){
int temp;
if (condition) {
temp = 1;![file](https://img2020.cnblogs.com/other/2120441/202011/2120441-20201124205042187-859391812.png)
} else{
temp = 2;
}
System.out.println(temp);
}
//优化后
public static void after(boolean condition){
int temp = condition ? 1 : 2;
System.out.println(temp);
}
二、把你学的枚举用起来
使用枚举类,完成对不同分支的逻辑判断,通过枚举便于集中管理逻辑条件,维护起来也更得心应手。代码如下:
//优化前
public static void before(String code) {
String msg = null;
if ("00001".equals(code)) {
msg = "缓存数据不能为空";
} else if ("00002".equals(code)) {
msg = "数据格式异常";
}
System.out.println(msg);
}
//优化后
public enum CacheEnums {
CACHE_DATA_IS_NULL("00001", "缓存数据不能为空"),
DATA_FORMATE_EXCEPTION("00002", "数据格式异常");
private String code;
private String msg;
CacheEnums(String code, String msg) {
this.code = code;
this.msg = msg;
}
public String getCode() {
return code;
}
public void setCode(String code) {
this.code = code;
}
public String getMsg() {
return msg;
}
public void setMsg(String msg) {
this.msg = msg;
}
public static CacheEnums of(String code){
for (CacheEnums temp : CacheEnums.values()) {
if (temp.getCode().equals(code)) {
return temp;
}
}
return null;
}
}
优化后的代码,在想获取msg时,一句话搞定,再也不用写一堆if-else了
//优化后
public static void after(String code) {
String msg = CacheEnums.of(code).getCode();
System.out.println(msg);
}
三、忘记你学的else(合理分析基础上)
在业务逻辑开发过程中,经常会写一些方法,会校验参数合法性,以及是否符合业务逻辑等检查,一旦不合条件,就会进行return或者是抛异常。有些同学的写法:
//优化前
public static int before(boolean condition1,boolean condition2) {
if (!condition1){
return 0;
}else if (condition2){
return 1;
}else{
return 99;
}
}
//优化后
public static int after(boolean condition1,boolean condition2) {
if (condition1){
return 0;
}
if (condition2){
return 1;
}
return 99;
}
四、策略模式
能够用的上策略模式的场景相对就更加特殊一些了,举个常见的例子,一个超市收银系统中的结算模块中会有很多种结算方式:双十一打折活动、满减活动、会员积分兑换消费券等等。他们都属于结算业务,那么就可以通过策略模式,设计不同的结算方式,达到解耦合和易扩展的目的。
接下来的代码以我项目中实际开发中用到的例子来说明,本次改造点是:在原有发送请求的的方法中增加将消息转发到其他平台的功能。考虑到以后可能会增加更多的平台,因此,这里采用策略模式,方便未来的功能扩展。以下为简版策略模式:
/**
* Description:顶层接口类
*/
public interface Route {
//定义处理方法
void handler(Object object);
}
/**
* Description:上下文信息
*/
public class RouteContext {
//策略模式的顶层接口
private Route route;
public RouteContext(Route route) {
this.route = route;
this.init();
}
//调用具体的策略中handler方法
public void handler(Route route, Object object) {
this.route = route;
route.handler(object);
}
public void init() {
//做一些数据的初始化
}
}
/**
* Description:策略一
*/
public class MQType implements Route{
@Override
public void handler(Object object) {
//这里是业务逻辑
}
}
/**
* Description:策略二
*/
public class OtherType implements Route{
@Override
public void handler(Object object) {
//这里是业务逻辑
}
}
搞定,这样就能够实现不同业务逻辑对应不同的实现类,再也不用一大坨代码揉在一块了,每一种路由方式都可以独立维护且易扩展,调用方也是无感知的。
更多文章请扫码关注或微信搜索Java栈点公众号!
更多文章请扫码关注或微信搜索Java栈点公众号!