PC的blog

@zhuxing

有些年頭了，不過寫java代碼還沒超過10年，你呢？

你覺得這樣做繁瑣，請問如何做才簡單？能不能貼出你認為簡單的代碼？有時候旁觀和自己動手做的感覺是完全不一樣的。還有，別忘了要把簡單留給使用你代碼的人，而把繁瑣留給自己。

有msn么？咱倆好好聊聊。：-）

@zhuxing

那個反射主要是為了分析@FactoryMethod注釋，用意很清晰：減少不必要的編碼。狀態增加后，程序員只需要增加一個帶@FactoryMethod的方法就行了。

申請加入，謝謝。

ID： polygoncell

@zhuxing

我又仔細的考慮了一下，覺得靜態方法在這里并不適用，因為我們需要針對不同的狀態寫出完全不同的邏輯來處理狀態。靜態方法通常適用于參數實例繁多而邏輯相同的情況。

@隔葉黃鶯

這位兄弟挺逗的！呵呵。那個4是怎么得來的？

兄弟沒必要這么針對我吧，我沒招惹你吧。真的是做個實驗，你可以看看我以前的文章。

哦，對了，樓上眾位兄弟哪位能夠幫我分析一下：我應該有如何處理自己原創的文章的自由吧？ 而且看與不看全憑自愿，為什么有些朋友的反應會這么激烈？最好那些反應過激的朋友能站出來說說你們的想法，大家交換一下意見，謝謝。

@BeanSoft

map沒有使用一大團if else，HashMap的代碼如下：

public V get(Object key) {
if (key == null)
return getForNullKey();
int hash = hash(key.hashCode());
for (Entry<K,V> e = table[indexFor(hash, table.length)];
e != null;
e = e.next) {
Object k;
if (e.hash == hash && ((k = e.key) == key || key.equals(k)))
return e.value;
}
return null;
}

而且Map已經封裝好了，對于我們使用者來說是沒有if else的。 現在編碼強調的是粒度適度，便于測試，便于閱讀。

@zhuxing

理論上來說，creation method也是可以的，不過這樣一來就導致Performer類和過多的其他類產生耦合（因為處理每一個狀態需要用到完全不同的類），我用factory就是為了保持performer干凈。要是一定要用creation method的話，performer都可以省了，直接寫一個復雜的enum，而每一個enum實例正好就是creation method。

@Unmi

我也就是這次試驗一下這么寫，效果不好的話會考慮下次換個方式。

@千里冰封

呵呵，可別超過3個。 對了，你的那個音樂播放器挺不錯的。

呵呵，大家的反應很激烈啊！

我這里只是使用一個簡單的例子來解釋如何使用重構來移除if else，實際應用邏輯當然要復雜很多。

的確有一些程序員覺得一個方法里面使用一大堆if else很方便，其實這只是對他自己方便，別人閱讀他的這一大堆if else會很頭疼。

我這樣重構看似增加了代碼量，實則封裝了大量的技術細節。

建議大家去讀讀refactoring to patterns這本書，書中就講到了一個結對重構（該書的作者和一個程序員）的例子，最開始那個程序員也覺得重構完后，代碼量明顯增加，他很不爽，但是后來他熟悉了那些模式后才發現他以前的做法是錯誤的，應該進行這樣的重構。

本書的命題是“入門和精通”，網上提供的章節僅僅是入門級別的內容，是為那些完全沒有Hibernate基礎的同學準備的。 那些已經了解Hibernate的同學一定會覺得這些章節很乏味，這是很正常的，因為你們已經掌握了這些入門級別的內容，再看一遍，自然乏味。但是請你們為那些從來沒有接觸過Hibernate的同學考慮一下，他們非常需要一個相對淺顯易懂的臺階來幫助他們“入門”。這就是我撰寫前幾章入門內容的初衷。

對于那些已經了解Hibernate的朋友們，請你們靜下心來閱讀后面深入內核的章節，在這些章節中，我是從構架的角度講解了Hibernate的幾個主要的模塊，舉例印證，圖文并茂，大部分內容源于實際項目。如果通讀完全書，還有朋友認為這本書“不怎么樣”，那么我作為這本書的作者，在這里誠心誠意的期盼著你們的寶貴意見，對于正確的意見，我將會在本書的后續版本中加以采納。

不論如何，非常感謝大家對本書的關注。