我在大厂做 CR——为什么建议使用枚举来替换布尔值
使用枚举替换布尔值主要基于以下几个原因
● 可读性
● 可拓展性
● 安全防控
可读性
我们会定义
boolean
类型(true
或false
)作为方法参数,虽然比较简洁,但有时候参数的含义往往不够清晰,造成阅读上的障碍,
比如:参数可能表示“是否开启某个功能”,但仅凭 true
和 false
并不能一眼看出其真实意图:
setDisable(false):到底是禁用还是启用 --!
setInvalid(false):到底是无效还是有效 --!
相信我,这种“绕弯”的“双重否定”表达方式,一定会耗费你不多的脑细胞一会儿:)
当然你可能会说:“不使用否定的名词”,换成“直接表达”,setEnable(true)
,这一眼能识别是启用,非常直观;
是的,没错,但在我 10 余年的编程生涯里,相信我 setDisable(false)
遇到过无数次;
再举个例子:
下面代码你能“一眼知道”参数 true
代表什么含义吗?
public static void main(String[] args) {
convert("12.3456", 2, true);
}
/**
* 将字符串转换成指定小数位数的值
*
* @param value
* @param scale
* @param enableHalfUp 是否需要四舍五入
* @return
*/
public static String convertToValue(String value, int scale, boolean enableHalfUp) {
if (enableHalfUp){
//将字符串"四舍五入"换成指定小数位数的值
}else{
//将字符串"截断"换到指定小数位数的值
}
}
当然,现在 IDE 都有比较好的提示,但从“可读性”角度,是不是只能进入到方法定义看注释去了解,甚至没有注释还得去翻代码去研究这个 boolean
到底是啥语义,参数再爆炸下,你能知道每个 boolean
类型参数代表什么吗?
convert("12.3456", 2, true,false,true,false,true);
这里额外扩展一句,木宛哥搞过一段时间的 iOS 开发,如果是 Objective-C 语言,方法命名采用了较为直观的格式,可以包含多个参数名称“线性叙事”,以提高可读性。这种情况,boolean 变量前往往有“名词修饰”,会容易理解,如下所示:
[NSString stringWithCString:"something" enableASCIIStringEncoding:true]
再从 OC 语言回过来,对于这个问题,让看看 JDK 是怎么设计的
public static void main(String[] args) {
BigDecimal value = new BigDecimal("12.34567");
//四舍五入到两位小数
BigDecimal roundedValue = value.setScale(2, RoundingMode.HALF_UP);
System.out.println(roundedValue);
}
看到了没,BigDecimal
的 setScale
方法,通过定义枚举:RoundingMode
代表转换规则,看到:RoundingMode.HALF_UP
一眼就知道要四舍五入,根本不需要看代码。
这样增加了可读性的,同时定义了枚举也支持更多扩展,如下马上引入第二点好处:可扩展;
可扩展性
如果未来需要增加更多状态,使用
boolean
会受到扩展的限制
例如,如果当前有两个状态:enable
(开)和 disable
(关),而将来需要添加待机
状态,使用 boolean
就显得不够灵活。枚举则很容易扩展,能够清晰地表示更多的状态。
使用 boolean
表达功能状态:
public void configureFeature(boolean enable) {
if (enable) {
// 开启功能
} else {
// 关闭功能
}
}
使用枚举表达功能状态:
public enum FeatureMode {
ENABLED,
DISABLED,
MAINTENANCE
}
public void configureFeature(FeatureMode mode) {
switch (mode) {
case ENABLED:
// 开启功能
break;
case DISABLED:
// 关闭功能
break;
case MAINTENANCE:
// 维护状态
break;
default:
throw new IllegalArgumentException("Unknown mode: " + mode);
}
}
类型安全
错误的使用 Boolean 包装类,有可能会引发空指针异常;
先抛一个问题:包装类 Boolean
有几种“值”?
Boolean
是包含两个值的枚举:Boolean.TRUE
和 Boolean.FALSE
;但别忘了,还可以是 null
;
一个真实的线上故障,Boolean
在某些情况下被错误地使用,可能会造成空指针异常;
例假设你正在修改一个老旧系统的某个方法,这个方法返回 Boolean
,有几千行代码:
public static void main(String[] args) {
if (checkIfMatched("Dummy")){
System.out.println("matched");
}
}
/**
* 老旧系统里一个异常复杂的方法,有几千行
* @param str
* @return
*/
public static Boolean checkIfMatched(String str) {
Boolean matched;
//假设此处存在:复杂处理逻辑,暂时用dummy代替
if ("Dummy".equals(str)) {
matched = true;
} else {
matched = false;
}
return matched;
}
目前没问题,但当功能不断迭代后,复杂度也陡然上升,在某个特别的分支里,没有对 Boolean
赋值,至少在编译时是不会报错的:
public static void main(String[] args) {
if (checkIfMatched("Dummy")) {
System.out.println("matched");
}
}
/**
* 老旧系统里一个异常复杂的方法,有几千行
*
* @param str
* @return
*/
public static Boolean checkIfMatched(String str) {
Boolean matched = null;
//假设此处存在:复杂处理逻辑,暂时用 dummy 代替
if ("Dummy".equals(str)) {
//模拟:代码在演进的时候,有可能存在 matched 未赋值情况
if (false) {
matched = true;
}
} else {
matched = false;
}
return matched;
}
这个时候,危险悄然而至,还记得上面的问题吗:
包装类 Boolean
有几种“值”?
现在 checkIfMatched()
方法在不同的情况下,方法会返回三个不同的值:true/false/null
这里 null
是非常危险的,如果上游使用如下方式判断条件,考虑下是否有问题?
if (checkIfMatched("Dummy")) {
System.out.println("matched");
}
首先这里不会编译错误,但此处 if
条件处会自动拆箱,对于 null
值会得到 NullPointerException
异常;
小小总结
再回过头看:“哪些场景建议使用枚举来替换布尔值”,我认为要看功能点的易变程度去综合评估:“越容易变化,越不能让复杂度发散,越要由一处收敛,试想下一个 Boolean
的方法的变动是不是要评估所有上游的业务”;
所以并不是完全推翻布尔值,木宛哥在此也只是抛出一些代码的优化手段仅供参考。