為什么阿里巴巴強(qiáng)制要求使用包裝類型定義屬性?
在阿里巴巴Java開發(fā)手冊中,對(duì)于POJO中如何選擇變量的類型也有著一些規(guī)定:
這里強(qiáng)制要求使用包裝類型,原因是什么呢?
我們來看一段簡單的代碼
- /**
 - * @author Hollis
 - */
 - public class BooleanMainTest {
 - public static void main(String[] args) {
 - Model model1 = new Model();
 - System.out.println("default model : " + model1);
 - }
 - }
 - class Model {
 - /**
 - * 定一個(gè)Boolean類型的success成員變量
 - */
 - private Boolean success;
 - /**
 - * 定一個(gè)boolean類型的failure成員變量
 - */
 - private boolean failure;
 - /**
 - * 覆蓋toString方法,使用Java 8 的StringJoiner
 - */
 - @Override
 - public String toString() {
 - return new StringJoiner(", ", Model.class.getSimpleName() + "[", "]")
 - .add("success=" + success)
 - .add("failure=" + failure)
 - .toString();
 - }
 - }
 
以上代碼輸出結(jié)果為:
- default model : Model[success=null, failure=false]
 
可以看到,當(dāng)我們沒有設(shè)置Model對(duì)象的字段的值的時(shí)候,Boolean類型的變量會(huì)設(shè)置默認(rèn)值為null,而boolean類型的變量會(huì)設(shè)置默認(rèn)值為false。
即對(duì)象的默認(rèn)值是null,boolean基本數(shù)據(jù)類型的默認(rèn)值是false。
也就是說,包裝類型的默認(rèn)值都是null,而基本數(shù)據(jù)類型的默認(rèn)值是一個(gè)固定值,如boolean是false,byte、short、int、long是0,float是0.0f等;
我們再舉一個(gè)扣費(fèi)的例子,我們做一個(gè)扣費(fèi)系統(tǒng),扣費(fèi)時(shí)需要從外部的定價(jià)系統(tǒng)中讀取一個(gè)費(fèi)率的值,我們預(yù)期該接口的返回值中會(huì)包含一個(gè)浮點(diǎn)型的費(fèi)率字段。當(dāng)我們?nèi)〉竭@個(gè)值得時(shí)候就使用公式:金額*費(fèi)率=費(fèi)用 進(jìn)行計(jì)算,計(jì)算結(jié)果進(jìn)行劃扣。
如果由于計(jì)費(fèi)系統(tǒng)異常,他可能會(huì)返回個(gè)默認(rèn)值,如果這個(gè)字段是Double類型的話,該默認(rèn)值為null,如果該字段是double類型的話,該默認(rèn)值為0.0。
如果扣費(fèi)系統(tǒng)對(duì)于該費(fèi)率返回值沒做特殊處理的話,拿到null值進(jìn)行計(jì)算會(huì)直接報(bào)錯(cuò),阻斷程序。拿到0.0可能就直接進(jìn)行計(jì)算,得出接口為0后進(jìn)行扣費(fèi)了。這種異常情況就無法被感知。
有人說,那我可以對(duì)0.0做特殊判斷,如果是0一樣可以阻斷報(bào)錯(cuò)啊。但是,這時(shí)候就會(huì)產(chǎn)生一個(gè)問題,如果允許費(fèi)率是0的場景又怎么處理呢?
所以,使用基本數(shù)據(jù)類型只會(huì)讓方案越來越復(fù)雜,坑越來越多。
這種使用包裝類型定義變量的方式,通過異常來阻斷程序,進(jìn)而可以被識(shí)別到這種線上問題。如果使用基本數(shù)據(jù)類型的話,系統(tǒng)可能不會(huì)報(bào)錯(cuò),進(jìn)而認(rèn)為無異常。
以上,就是建議在POJO和RPC的返回值中使用包裝類型的原因。
















 
 
 






 
 
 
 