一個開發原則：永遠不要返回NULL

看一篇文章：10個經典的java開發原則，裏面一個原則：永遠不要返回NULL。

說實在的，我對這個原則體會不是很深，平時在使用對象前，檢查是否爲null已經成了習慣，也是我要求開發人員的一個標準動做。可是文中提的也有必定的道理。所以就拿過來討論了下。

---------------------------------

爲何，由於不少代碼都是 a.b(......).c(...) 這麼連着調用。若是每層調用都要檢查是否爲空的話，代碼就太難看了，也太麻煩了。有沒有更好的解決方法呢？

可是不返回null，返回什麼呢？顯然要反悔一個類的實例，可是怎麼保證獲得的結果是預期的呢，也就是說，怎麼能保證這樣雖然不會報「未交對象引用設置到對象的實例」（實際上就是空引用）這個錯誤，可是能獲得「正確」的結果呢。顯然，應該是nul可是沒有返回null是得不到正確的結果，可是咱們要保證結果是可控的，也就是說，雖然代碼順利執行下來了，可是咱們要知道實際上啥也不該該作。或者，咱們要針對這種狀況，返回能夠接受的結果。

至於什麼事能夠接受的結果，這個有麼有必定的原則和規律呢，仍是須要具體問題具體分析呢？體育老師教的語文，本身都以爲沒說明白，繞！

一類裏要有個標誌，表示出「雖然是個非空的實例，可是它確實表明null」這個意思。問題接着追下去，若是是這個意思的話，那麼他的方法應該作什麼呢？也就是要解答：若是不存在這個實例，那麼這個方法應該是什麼業務邏輯。搞清楚了這個，就能夠寫這樣的代碼了：

假設那個標誌命名爲  nullInstance；

if ( nullINstance ) then {

      不存在這個實例的業務邏輯；

}else{

     正常的業務邏輯。

}

 

這麼說太抽象了，咱們舉個實際的例子吧。

設計以下簡單場景：刪除員工所屬的部門，

（1）員工類：employee，

（2）員工所屬部門（咱們用方法來表示吧，不用屬性了，爲了說明問題）：getDepartment()

（3）部門類：department；

（4）部門的刪除方法：delete();

那麼：

  getDepartment（）{

      if（ nullINstance  ）｛ //若是員工類是空的話

　      return new Department( nullInstance=true ); //建立一個」空「實例；

     ｝

      else{

          return new department( thisd.deptID); //返回一個具體的部門類

     }

  }

 

 那麼：類department.delete()的實現：

 delete(){

     if（ nullINstance  ）｛ //若是空的話

          return ;

    else 

        執行刪除方法：delete from department where deptid = 2222;

}

 

考，這也夠麻煩的啊！不過麻煩我一個，方便千萬人。雷鋒精神永垂不朽！

是這樣嗎？沒有把握。