※ 引述《samtree (嗯....？)》之銘言：
: ※ 引述《awert ( )》之銘言：
: : 理論上是第二種，差別單純在於
: : a如果是null時，不會有NullPointerException
: : 但我覺得微調這個沒有太大意義就是了..
: 對我而言
: 這兩種寫法已經不是哪種較好的問題了
: 第一種寫法根本就是錯誤的寫法
: （當然如果你百分之百確定該字串絕對不會是null)
: 或是你真的需要丟 nullPointerException
: (不過例外處理的成本比判斷是否為 null 高出許多）
用推文有點慢..
我的想法是這樣子的，這個idiom並沒有問題。
但是，實際寫code時遇到要處理null問題時，
我不會鑽牛角尖考慮哪一種處理null的方式比較漂亮/有效率，
而是要先看為什麼要處理null。
有時候要判斷為null都是因為其他code不必要的動作
舉例來講
public String getString() {
if (someCondition()) {
return myString;
}
return null; // bad
}
public String getList() {
if (hasMoreThanZero()) {
return myList;
}
return null; // bad
}
上面第一個method可以考慮使用空字串，第二個則是空list如Collections.emtpyList()
如果是物件，那麼是否能用null object ? 這些都是可能可以改進的地方，
當然，有時候這些東西不是單一一個programmer可以去決定的事，
也不會這麼巧都可以解決，所以我們得乖乖的處理null。
這時，就要考慮到第二點，怎麼處理比較有效率。關於這點，
我認為是不需要考慮，等到是因為這樣而造成效率低落時再說，
更何況其實上面的寫法也只是將判斷丟給String的equals裡面。
第三點是，是否該允許null出現
如果a不該為null，那麼這個idiom不就隱藏了一個可能潛在的問題 ?
最後一點則是比較我個人較龜毛的想法，
SOME_CONSTANTS.equals(a)乍看之下很棒，不需要去處理
可是當實際他人在維護/更改code時，可能會造成一點困擾，
因為code裡並沒有清楚的提醒閱讀者，這個a可能是null。
--
We who cut mere stones must always be envisioning cathedrals.
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 114.35.186.241
→
02/01 01:22, , 1F
02/01 01:22, 1F
推
02/03 01:22, , 2F
02/03 01:22, 2F
討論串 (同標題文章)