Java基礎學習總結（127）——Java方法應該返回Null 物件還是null，javanull

Java基礎學習總結（127）——Java方法應該返回Null 物件還是null，javanull
Java方法應該返回Null 物件還是null? 大多數情況下就是在需要傳回值的方法中，使用Null 物件（empty object）來代替返回null。理由很簡單，Null 物件與其他有意義的對象一樣，使得調用方法的使用者不需要區分傳回值，即不需要判斷傳回值是否為null，從而簡化了用戶端調用（不必在使用傳回值之前進行 if 判斷）；另外也使得用戶端的代碼更不容易出錯（如果有粗心的程式員或者自己忘了判斷null）。
我覺得這又是一個很糾結的問題，我現在在做的項目就飽受這個問題帶來的痛苦。在當前的項目中，幾乎所有的方法（項目中建立的）都使用null傳回型別，不管是String還是集合類。
例如：
List<User> getUsers(){
if(!validation()){
return null;
}//return a ArrayList containing logic data
}
這樣就造成所有使用到這個方法的地方都要在使用傳回值之前進行null判斷，
比如for迴圈之前，比如retainAll()之前，比如size()之前。這還不是最痛苦的，最痛苦的是，並不是所有的方法都返回null，有的地方返回的是一個空的ArrayList。這種方法有一些是項目內的，
有一些是第三方類庫的。於是，為了健壯性，不管3X7=21，對於任何方法的傳回值，在使用前都先進行null判斷，天知道其他人會不會在下一刻就把方法的傳回值從Null 物件變成null了。
所以，一翻開代碼就能看到大批的if語句，如果再跟一些條件陳述式和for語句混合在一起，簡直就是災難。那究竟該如何面對這個問題？在什麼地方應該返回null，什麼地方返回Null 物件？
1.對於集合和數組作為傳回值，使用長度為零的數組或者集合，而不是null。這樣做的好處實在太多了：
a.簡化代碼，不需要調用者在使用傳回值之前進行null判斷，不管是size()，for()，集合操作都OK。
b.增強程式的健壯性，既然傳回值不是null，就不用擔心NullPointer這個無處不在的異常。反對者一般都從效能的角度來考慮，認為這樣增加了系統的開銷。對於這一點，我覺得挺有意思，
我見過太多的程式員寫出來一些很不好的設計，例如很爛的異常處理與演算法迴圈，但是他們卻對於這個空集合十分在意。我本人對於效能沒有太高的sense，我覺得對於像我這種僅僅勉強能保證程式健壯性的菜鳥來說，
過多的考慮效能問題是不實際的。我不僅沒有那個能力，並且很有可能把事情做的更糟。這裡借用Effective Java書中的話，在這個層級上擔心效能問題是不明智的，除非分析表明這個方法正是造成效能問題的真正源頭。
另外，他還提到，我們可以在程式中返回可重用的Null 物件，例如一個長度為零的數組或者是emptyList/emptySet(這些都在Collections類中定義)，這樣，在我們整個程式周期，都會只分配這一個Null 物件。
當然，這裡有個問題，如果你返回的List將來還希望有修改的操作，
例如:
List<User> users = getUsers();
users.add(user);
那麼返回Collections.emptyList()就是不合理的，整個空集合并不能修改，它並不是一個ArrayList或者LinkedList，它僅僅是List介面的一個實現。
2.字串作為傳回值，使用Null 字元串來代替null。我們經常有方法返回字串，很多時候都會進行字串的拼接或者equals或者split等，如果傳回值為空白，我們就必須進行null判斷。對於字串拼接，
倒不會報出NullPointer異常，但是會被當成"null"來使用，這更詭異。例如：String a=null;String b = a + "B";//result: nullB
3.任何在邏輯上表示尋找(search或者get)的意思時，應該返回null。例如下面這個方法就是不合理的User getUserById(String id){User user = dao.getUserById(id);if(user == null)return new User();return user;}
4.當Null 物件與其他返回對象有一樣的行為和意義時，使用Null 物件例如，有一個方法返回一個迭代器。一個空的迭代器可以定義為NullIterator並實現Iterator介面，他的next方法永遠返回null，
他的hasNext方法永遠返回false。這樣，使用這個方法傳回值的代碼就不要進行null判斷，因為NullIterator的行為與其他迭代器一樣。光談到使用的場合還不夠，對於項目而言，還需要項目約束來制約開發人員的行為，否則必然是一團糟，因為誰都不相信誰。 查看評論