章節三 代碼的壞味道
*這一部分的內容最好在CHM文件中去閱讀
Duplicated Code （重複代碼）
同一個class內的兩個函數含有相同表達式（expression）
採用Extract Method提煉出重複的代碼，然後讓這兩個地點都調用被提煉出來的那一段代碼。
兩個互爲兄弟〔sibling）的subclasses內含相同表達式
對兩個classes都使用Extract Method，然後再對被提煉出來的代碼使用 Pull Up Field，將它推入superclass內。如果代碼之 間只是類似，並非完全相同，那麼就得運用Extract Method將相似部分和差異部分割開，構成單獨一個函數。然後你可能發現或許可以運用Form Template Method獲得一個Template Method設計模式。如果有些函數以不同的算法做相同的事，你可以擇定其中較清晰的一個，並使用Substitute Algorithm將其他函數的算法替換掉。
兩個毫不相關的classes內出現Duplicated Code
應該考慮對其中一個使用Extract Class，將重複代碼提煉到一個獨立class中，然後在另一個class內 使用這個新class。但是，重複代碼所在的函數也可能的確只應該屬於某個class， 另一個class只能調用它，抑或這個函數可能屬於第三個class，而另兩個classes應該引用這第三個class。你必須決定這個函數放在哪兒最合適，並確保它被安置後就不會再在其他任何地方出現。
Long Method（過長函數）
讓small method容易理解的真正關鍵在於一個好名字。如果你能給函數起個好名字，讀者就可以通過名字瞭解函數的作用，根本不必去看其中寫了些什麼。
遵循這樣一條原則：==每當感覺需要以註釋來說明點什麼的時候，我們就把需要說明的東西寫進一個獨立函數中，並以其用途（而非實現手法）命名。== 我們可以對一組或甚至短短一行代碼做這件事。哪怕替換後的函數調用動作比函數自身還長，只要函數名稱能夠解釋其用途，我們也該毫不猶豫地那麼做。關鍵不在於函數的長度，而在於函數「做什麼」和「如何做」之間的語義距離。
Large Class（過大類）
可以運用Extract Class將數個變量一起提煉至新class內。提煉時應該選擇class內彼此相關的變量，將它們放在一起。
Long Parameter List（過長參數列）
如果「向既有對象發出一條請求」就可以取得原本位於參數列上的一份數據，那麼 你應該激活重構準則Replace Parameter with Method 。上述的既有對象可能是函數所屬class內的一個值域（field），也可能是另一個參數。你還可以運用Preserve Whole Object 將來自同一對象的一堆數據收集起來，並以該對象替換它們。如果某些數據缺乏合理的對象歸屬，可使用Introduce Parameter Object 爲它們製造出一個「參數對象」。
Divergent Change（發散式變化）
如果某個class經常因爲不同的原因在不同的方向上發生變化，Divergent Change就出現了。當你看着一個class說：『呃，如果新加入一個數據庫，我必須修改這三個函數；如果新出現一種金融工具，我必須修改這四個函數』，那麼此時也許將這個對象分成兩個會更好，這麼一來每個對象就可以只因一種變化而需要修改。當然，往往只有在加入新數據庫或新金融工具後，你才能發現這一點。==針對某一外界 變化的所有相應修改，都只應該發生在單一class中，== 而這個新class內的所有內容都應該反應該外界變化。爲此，你應該找出因着某特定原因而造成的所有變化，然後運用Extract Class 將它們提煉到另一個class中。
Shotgun Surgery（散彈式修改）
Shotgun Surgery類似Divergent Change，但恰恰相反。如果每遇到某種變化，你都必須在許多不同的classes內做出許多小修改以響應之，你所面臨的壞味道就是Shotgun Surgery。如果需要修改的代碼散佈四處，你不但很難找到它們，也很容易忘記某個重要的修改。
這種情況下你應該使用Move Method 和 Move Field 把所有需要修改的代碼放進同一個class。如果眼下沒有合適的可以安置這些代碼，就創造一 個。通常你可以運用Inline Class 把一系列相關行爲放進同一個class。這可能會造成少量Divergent Change，但你可以輕易處理它。
Feature Envy（依戀情結）
函數對某個class的興趣高過對自己所處之host class的興趣。這種孺慕之情最通常的焦點便是數據。無數次經驗裏，我們看到某個函數 爲了計算某值，從另一個對象那兒調用幾乎半打的取值函數（getting method）。療法顯而易見：把這個函數移至另一個地點。你應該使用Move Method 把它 移到它該去的地方。有時候函數中只有一部分受這種依戀之苦，這時候你應該使用 Extract Method 把這一部分提煉到獨立函數中，再使用Move Method 帶它去它的夢中家園。
當然，並非所有情況都這麼簡單。一個函數往往會用上數個特性，那麼它究竟該被置於何處呢？我們的原則是：==判斷哪個class擁有最多「被此函數使用」的數據，然後就把這個函數和那些數據擺在一起==。如果先以Extract Method 將這個函數分解爲數個較小函數並分別置放於不同地點，上述步驟也就比較容易完成了。
有數個複雜精巧的模式(patterns)破壞了這個規則。說起這個話題，「四巨頭」[Gang of Four]的Strategy 和Visitor立刻跳入我的腦海，Kent Beck 的 Self Delegation [Beck]也在此列。使用這些模式是爲了對抗壞味道Divergent Change。最根本的原則是：將總是一起變化的東西放在一塊兒。「數據」和「引用這些數據」的行爲總是一起變化的，但也有例外。如果例外出現，我們就搬移那些行爲，保持「變化只在一地發生」。Strategy 和Visitor『使你得以輕鬆修改函數行爲，因爲它們將少量需被覆寫〔overridden）的行爲隔離開來——當然也付出了「多一層間接性」的 代價。
Data Clumps（數據泥團）
數據項（data items）就像小孩子：喜歡成羣結隊地待在一塊兒。你常常可以在很多地方看到相同的三或四筆數據項：兩個classes內的相同值域（field）、許多函數簽名式（signature）中的相同參數。這些「總是綁在一起出現的數據」真應該放進屬於它們自己的對象中。==首先請找出這些數據的值域形式（field）出現點，運用Extract Class 將它們提煉到一個獨立對象中。== 然後將注意力轉移到函數簽名式（signature）上頭，運用Introduce Parameter Object 或Preserve Whole Object 爲它減肥。這麼做的直接好處是可以將很多參數列縮短，簡化函數調用動作。是的，不必因爲Data Clumps只用上新對象的一部分值域而在意，只要你以新對象取代兩個（或更多）值域，你就值回票價了。
一個好的評斷辦法是：刪掉衆多數據中的一筆。其他數據有沒有因而失去意義？如果它們不再有意義，這就是個明確信號：你應該爲它們產生一個新對象。
Primitive Obsession（基本型別偏執）
大多數編程環境都有兩種數據：結構型別（record types）允許你將數據組織成有意義的形式；基本型別（Primitive type）則是構成結構型別的積木塊。結構總是會帶 來一定的額外開銷。
對象的一個極具價值的東西是：它們模糊（甚至打破）了橫亙於基本數據和體積較大的classes之間的界限。你可以輕鬆編寫出一些與語言內置（基本〕型別無異的小型classes。例如Java就以基本型別表示數值，而以class表示字符串和日期。
對象技術的新手通常不願意在小任務上運用小對象——像是結合數值和幣別的 money classes 、含一個起始值和一個結束值的range classes、電話號碼或郵政編碼（ZIP） 等等的特殊strings。你可以運用Replace Data Value with Object 將原本單獨存在的數據值替換爲對象，從而走出傳統的洞窟，進入炙手可熱的對象世界。如果欲替換之數據值是 type code（型別碼），而它並不影響行爲，你可以運用 Replace Type Code with Class 將它換掉。如果你有相依於此 type code的條件式，可運用 Replace Type Code with Subclasses 或 Replace Type Code with State/Strategy 加以處理。
如果你有一組應該總是被放在一起的值域（fields），可運用Extract Class。 如果你在參數列中看到基本型數據，不妨試試Introduce Parameter Object。 如果你發現自己正從array中挑選數據，可運用Replace Array with Object。
Switch Statements（switch驚悚現身）
面向對象程序的一個最明顯特徵就是：少用switch (或case）語句。從本質上說， switch語句的問題在於重複（duplication）。你常會發現同樣的switch語句散佈 於不同地點。如果要爲它添加一個新的子句，你必須找到所有switch語句 並修改它們。面向對象中的多態（polymorphism ）概念可爲此帶來優雅的解決辦法。
大多數時候，一看到switch語句你就應該考慮以「多態」來替換它。問題是態 該出現在哪兒？switch語句常常根據 type code（型別碼）進行選擇，你要的是「與 該 type code相關的函數或class」。所以你應該使用Extract Method 將switch語句提煉到一個獨立函數中，再以Move Method 將它搬移到需要多態性的那個class裏頭。此時你必須決定是否使用 Replace Type Code with Subclasses 或 Replace Type Code with State/Strategy。一旦這樣完成繼承結構之後， 你就可以運用Replace Conditional with Polymorphism了。
如果你只是在單一函數中有些選擇事例，而你並不想改動它們，那麼「多態」就有 點殺雞用牛刀了。這種情況下Replace Parameter with Explicit Methods是個不錯的選擇。如果你的選擇條件之一是null，可以試試Introduce Null Object。
Parallel Inheritance Hierarchies（平行繼承體系）
Parallel Inheritance Hierarchies其實是shotgun surgery的特殊情況。在這種情況下，每當你爲某個class增加一個subclass，必須也爲另一個class相應增加一個subclass。如果你發現某個繼承體系的名稱前綴和另一個繼承體系的名稱前綴完全相同，便是聞到了這種壞味道。
消除這種重複性的一般策略是：讓一個繼承體系的實體（instance）指涉（參考、引用、refer to）另一個繼承體系的實體(instances)。如果再接再厲運用Move Method 和 Move Field，就可以將指涉端（ referring class ）的繼承體系消弭於無形。
Lazy Class（冗贅類）
你所創建的每一個class，都得有人去理解它、維護它，這些工作都是要花錢的。==如 果一個class的所得不值其身價，它就應該消失。== 項目中經常會出現這樣的情況： 某個class原本對得起自己的身價，但重構使它身形縮水，不再做那麼多工作；或開發者事前規劃了某些變化，並添加一個class來應付這些變化，但變化實際上沒 有發生。不論上述哪一種原因，請讓這個class莊嚴赴義吧。如果某些subclass沒有做滿足夠工作，試試 Collapse Hierarchy。對於幾乎沒用的組件，你應該以Inline Class對付它們。
Speculative Generality（誇誇其談未來性）
當有人說『噢，我想我們總有一天需要做這事』並因而企圖以各式各樣的掛勾（hooks）和特殊情況來處理一 些非必要的事情，這種壞味道就出現了。那麼做的結果往往造成系統更難理解和維護。如果所有裝置都會被用到，那就值得那麼做；如果用不到，就不值得。 用不上的裝置只會擋你的路，所以，把它搬開吧。
如果你的某個abstract class其實沒有太大作用，請運用Collapse Hierarchy。非必要之delegation （委託）可運用Inline Class 除掉。如果函數的某些參數未被用上，可對它實施 Remove Parameter。如果函數名稱帶有多餘的抽象意味，應該對它實施Rename Method 讓它現實一些。
如果函數或class的惟一用戶是test cases （測試用例），這就飄出了壞味道Speculative Generality。如果你發現這樣的函數或class，請把它們連同其test cases都刪掉。但如果它們的用途是幫助test cases檢測正當功能，當然必須刀下留人。
Temporary Field（令人迷惑的暫時值域）
有時你會看到這樣的對象：其內某個instance變量僅爲某種特定情勢而設。這樣的代碼讓人不易理解，因爲你通常認爲對象在所有時候都需要它的所有變量。在變量未被使用的情況下猜測當初其設置目的，會讓你發瘋。
請使用 Extract Class 給這個可憐的孤兒創造一個家，然後把所有和這個變 量相關的代碼都放進這個新家。也許你還可以使用 Introduce Null Object 在「變量不合法』的情況下創建一個Null對象，從而避免寫出『條件式代碼」。
如果class中有一個複雜算法，需要好幾個變量，往往就可能導致壞味道Temporary Field的出現。由於實現者不希望傳遞一長串參數（想想爲什麼），所以他把這些 參數都放進值域（field）中。但是這些值域只在使用該算法時纔有效，其他情況下只會讓人迷惑。這時候你可以利用 Extract Class 把這些變量和其相關函數提煉到一個獨立class中。提煉後的新對象將是一個method object[Beck]（譯註：其存在只是爲了提供調用函數的途徑，class本身並無抽象意味）。
Message Chains（過度耦合的消息鏈）
如果你看到用戶向一個對象索求（request）另一個對象，然後再向後者索求另一個對象，然後再索求另一個對象……這就是Message Chains。實際代碼中你看到的可 能是一長串getThis()或一長串臨時變量。採取這種方式，意味客戶將與查找過程中的航行結構（structure of the navigation）緊密耦合。一旦對象間的關係發生任何變化，客戶端就不得不做出相應修改。
這時候你應該使用Hide Delegate。你可以在Message Chains的不同位置進行這種重構手法。理論上你可以重構Message Chains上的任何一個對象，但這麼做往往會把所有中介對象（intermediate object ）都變成Middle Man。通常更好的選擇是：==先觀察Message Chains最終得到的對象是用來幹什麼的，看看能否以 Extract Method 把使用該對象的代碼提煉到一個獨立函數中，再運用Move Method 把這個函數推入Message Chains。== 如果這條鏈上的某個對象有多位客戶打算航行此航線的剩餘部分，就加一個函數來做這件事。
有些人把任何函數鏈（method chain。譯註：就是Message Chains；面向對象領域中所謂「發送消息」就是「調用函數」）都視爲壞東西，我們不這樣想。呵呵，我們的冷靜鎮定是出了名的，起碼在這件事情上是這樣。
Middle Man（中間轉手人）
對象的基本特徵之一就是封裝（encapsulation）——對外部世界隱藏其內部細節。封裝往往伴隨delegation （委託）。
但是人們可能過度運用delegation。你也許會看到某個class接口有一半的函數都委託給其他class，這樣就是過度運用。這時你應該使用Remove Middle Man，直接和實責對象打交道。如果這樣「不幹實事」的函數只有少數幾個，可以運用 Inline Method 把它們” Inlining”，放進調用端。如果這些Middle Man還有其他行 爲，你可以運用 Replace Delegation with Inheritance 把它變成實責對象的subclass，這樣你既可以擴展原對象的行爲，又不必負擔那麼多的委託動作。
Inappropriate Intimacy（狎暱關係）
有時你會看到兩個classes過於親密，花費太多時間去探究彼此的private成分。如果這發生在兩個「人」之間，我們不必做衛道之士；但對於classes，我們希望它們嚴守清規。
就像古代戀人一樣，過份狎暱的classes必須拆散。你可以採用 Move Method 和 Move Field 幫它們劃清界線，從而減少狎暱行徑。你也可以看看是否運用 Change Bidirectional Association to Unidirectional 讓其中一個class對另一個斬斷情絲。如果兩個實在是情投意合，可以運用Extract Class 把兩者共同點提煉到一個安全地點，讓它們坦蕩地使用這個新class。或者也可以嘗試運用 Hide Delegate 讓另一個class來爲它們傳遞相思情。
繼承（inheritance）往往造成過度親密，因爲subclass對superclass的瞭解總是超過superclass的主觀願望。如果你覺得該讓這個孩子獨自生活了，請運用Replace Delegation with Inheritance 讓它離開繼承體系。
Alternative Classes with Different Interfaces（異曲同工的類）
如果兩個函數做同一件事，卻有着不同的簽名式（signatures），請運用Rename Method 根據它們的用途重新命名。但這往往不夠，請反覆運用Move Method 將某些行爲移入classes，直到兩者的協議（protocols ）一致爲止。如果你必須重複而贅餘地移入代碼才能完成這些，或許可運用Extract Superclass 爲自己贖 點罪。
Incomplete Library Class（不完美的程序庫類）
複用（reuse）常被視爲對象的終極目的。我們認爲這實在是過度估計了（我們只是使用而己）。但是無可否認，許多編程技術都建立在library classes （程序庫類）的基礎上，沒人敢說是不是我們都把排序算法忘得一乾二淨了。
library classes構築者沒有未卜先知的能力，我們不能因此責怪他們。畢竟我們自己也幾乎總是在系統快要構築完成的時候才能弄清楚它的設計，所以library 構築者的任務真的很艱鉅。麻煩的是library的形式（form）往往不夠好，往往不可能讓我們修改其中的classes使它完成我們希望完成的工作。這是否意味那些經過實踐檢驗的戰術如 Move Method 等等，如今都派不上用場了？
幸好我們有兩個專門應付這種情況的工具。如果你只想修改library classes內的一兩 個函數，可以運用 Introduce Foreign Method；如果想要添加一大堆額外行爲，就得運用Introduce Local Extension。
Data Class（純稚的數據類）
所謂Data Class是指：它們擁有一些值域（fields），以及用於訪問（讀寫〕這些值域的函數，除此之外一無長物。這樣的classes只是一種「不會說話的數據容器」，它們幾乎一定被其他classes過份細瑣地操控着。這些classes早期可能擁有public值域，果真如此你應該在別人注意到它們之前，立刻運用Encapsulate Field 將它們封裝起來。如果這些classes內含容器類的值域（collection fields），你應該 檢査它們是不是得到了恰當的封裝；如果沒有，就運用 Encapsulate Collection 把它們封裝起來。對於那些不該被其他classes修改的值域，請運用 Remove Setting Method。
然後，==找出這些「取值/設值」函數（getting and setting methods）被其他classes運用的地點。嘗試以Move Method 把那些調用行爲搬移到Data Class來==。如果無法搬移整個函數，就運用 Extract Method 產生一個可被搬移的函數。不久之後你就可以運用Hide Method 把這些「取值/設值」函數隱藏起來了。
Data Class就像小孩子。作爲一個起點很好，但若要讓它們像「成年（成熟）」的對象那樣參與整個系統的工作，它們就必須承擔一定責任。
Refused Bequest（被拒絕的遺贈）
Subclasses 應該繼承superclasses的函數和數據。但如果它們不想或不需要繼承，又該怎麼辦呢？
按傳統說法，這就意味繼承體系設計錯誤。你需要爲這個subclass 新建一個兄弟（sibling class），再運用Push Down Method 和 Push Down Field 把所有用不到的函數下推給那兄弟。這樣一來superclass就只持有所有subclasses共享的東西。常常你會聽到這樣的建議：所有superclasses都應該是抽象的（abstract）。
既然使用「傳統說法」這個略帶貶義的詞，你就可以猜到，我們不建議你這麼做，起碼不建議你每次都這麼做。我們經常利用subclassing手法來複用一些行爲，並發現這可以很好地應用於日常工作。這也是一種壞味道，我們不否認，但氣味通常並不強烈。所以我們說：如果Refused Bequest引起困惑和問題，請遵循傳統忠告。但不必認爲你每次都得那麼做。十有八九這種壞味道很淡，不值得理睬。
如果subclass複用了superclass的行爲（實現），卻又不願意支持superclass的接口，Refused Bequest的壞味道就會變得濃烈。拒絕繼承superclass的實現，這一點我們不介意；但如果拒絕繼承superclass的接口，我們不以爲然。不過即使你不願意繼承接口，也不要胡亂修改繼承體系，你應該運用Replace Inheritance with Delegation 來達到目的。
Comments（過多的註釋）
別擔心，我們並不是說你不該寫註釋。從嗅覺上說，Comments不是一種壞味道；事實上它們還是一種香味呢。我們之所以要在這裏提到Comments，因爲人們常把它當作除臭劑來使用。常常會有這樣的情況：你看到一段代碼有着長長的註釋，然後發現，這些註釋之所以存在乃是因爲代碼很糟糕。這種情況的發生次數之多，實 在令人吃驚。
Comments可以帶我們找到本章先前提到的各種壞味道。找到壞味道後，我們首先應該以各種重構手法把壞味道去除。完成之後我們常常會發現：註釋已經變得多餘了，因爲代碼已經清楚說明了一切。
如果你需要註釋來解釋一塊代碼做了什麼，試試 Extract Method；如果method已經提煉出來，但還是需要註釋來解釋其行爲，試試Rename Method；如果你需要註釋說明某些系統的需求規格，試試 Introduce Assertion。
TIP：當你感覺需要撰寫註釋，請先嚐試重構，試着讓所有註釋都變得多餘。
如果你不知道該做什麼，這纔是註釋的良好運用時機。除了用來記述將來的打算之外，註釋還可以用來標記你並無十足把握的區域。你可以在註釋裏寫下自己「爲什 麼做某某事」。這類信息可以幫助將來的修改者，尤其是那些健忘的傢伙。
