03.02 StackOverflow經典問題:代碼中如何去掉煩人的“!=null"判空語句

問題

為了避免空指針調用,我們經常會看到這樣的語句

<code>if (someobject != null) {    someobject.doCalc();}/<code>

最終,項目中會存在大量判空代碼,多麼醜陋繁冗!如何避免這種情況?我們是否濫用了判空呢?

回答

這是初、中級程序猿經常會遇到的問題。

他們總喜歡在方法中返回null,因此,在調用這些方法時,也不得不去判空。

另外,也許受此習慣影響,他們總潛意識地認為,所有的返回都是不可信任的,為了保護自己程序,就加了大量的判空。

吐槽完畢,回到這個題目本身,進行判空前,請區分以下兩種情況:

  • null 是一個有效有意義的返回值(Where null is a valid response in terms of the contract; and)
  • null是無效有誤的(Where it isn't a valid response.)

你可能還不明白這兩句話的意思.

不急,繼續往下看,接下來將詳細討論這兩種情況

先說第2種情況:null就是一個不合理的參數,就應該明確地中斷程序,往外拋錯誤。

這種情況常見於api方法。

例如你開發了一個接口,id是一個必選的參數,如果調用方沒傳這個參數給你,當然不行。你要感知到這個情況,告訴調用方“嘿,哥們,你傳個null給我做甚"。

相對於判空語句,更好的檢查方式有兩個

  • assert語句,你可以把錯誤原因放到assert的參數中,這樣不僅能保護你的程序不往下走,而且還能把錯誤原因返回給調用方,豈不是一舉兩得。(原文介紹了assert的使用,這裡省略)
  • 也可以直接拋出空指針異常。上面說了,此時null是個不合理的參數,有問題就是有問題,就應該大大方方往外拋。

第1種情況會更復雜一些: 這種情況下,null是個”看上去“合理的值。

例如,我查詢數據庫,某個查詢條件下,就是沒有對應值,此時null算是表達了“空”的概念。

這裡給一些實踐建議:

假如方法的返回類型是collections,當返回結果是空時,你可以返回一個空的collections(empty list),而不要返回null,這樣調用側就能大膽地處理這個返回。例如調用側拿到返回後,可以直接print list.size(),又無需擔心空指針問題。

什麼?想調用這個方法時,不記得之前實現該方法有沒按照這個原則?

所以說,代碼習慣很重要!如果你養成習慣,都是這樣寫代碼,返回空collections而不返回null),你調用自己寫的方法時,就能大膽地忽略判空。

返回類型不是collections,又怎麼辦呢?那就返回一個空對象(而非null對象),下面舉個“栗子”,假設有如下代碼

StackOverflow經典問題:代碼中如何去掉煩人的“!=null

其中,Parse有一個接口FindAction,這個接口會依據用戶的輸入,找到並執行對應的動作。假如用戶輸入不對,可能就找不到對應的動作(Action),因此findAction就會返回null,接下來action調用doSomething方法時,就會出現空指針。解決這個問題的一個方式,就是使用Null Object pattern(空對象模式)

我們來改造一下

類定義如下,這樣定義findAction方法後,確保無論用戶輸入什麼,都不會返回null對象:

StackOverflow經典問題:代碼中如何去掉煩人的“!=null

對比下面兩份調用實例

冗餘: 每獲取一個對象,就判一次空

StackOverflow經典問題:代碼中如何去掉煩人的“!=null

精簡

<code>ParserFactory.getParser().findAction(someInput).doSomething();/<code>

因為無論什麼情況,都不會返回空對象,因此通過findAction拿到action後,可以放心地調用action的方法。

其他回答精選:

如果要用equal方法,請用object.equal(object)) 例如:使用 "bar".equals(foo) 而不是 foo.equals("bar")

Java8或者guava lib中,提供了Optional類,這是一個元素容器,通過它來封裝對象,可以減少判空。不過代碼量還是不少。不爽。

如果你想返回null,請停下來想一想,這個地方是否更應該拋出一個異常


分享到:


相關文章: