今天延續上一篇的壞味道繼續節錄XD
9. Primitive Obsession (基本型別偏執)
大多數的編程環境都有兩種資料：結構型別(record types)允許你將資料組織成有意義的形式；基本型態(primitive
types)則是構成結構型別的積木塊。結構總是會帶來一定的額外開銷。一般程式語言中物件技術的新手通常不願意在小任務上運用小物件。
10. Switch Statements (switch驚悚現身)
物件導向程式的一個最明顯特徵就是：少用switch(或case)述句。從本質上說，switch述句的問題在於重複(duplication)。你常會發現同樣的switch述句散佈於不同地點。如果要為它添加一個新的case子句，你必須找到所有switch述句並修改它們。
11. Parallel Inheritance Hierarchies
(平行繼承體系)
在這種情況下，每當你為一個class新增一個subclass，必須也為另一個class相應增加一個subclass。如果你發現某個繼承體系的class名稱字首和另一個繼承體系的class名稱字首完全相同，便是聞到了這種壞味道。
12. Lazy Class (冗員類別)
你所創建的每一個class，都得有人去理解它、維護它，這些工作都要花錢的。如果一個class的所得不值其身價，它就應該消失。
13. Speculative Generality (夸夸其談未來性)
當有人說『噢，我想我們總有一天需要做這種事』並因而企圖以各式各樣的掛勾(hooks)和特殊情況來處理一些非必要的事情，這種壞味道就出現了。那麼做的結果往往造成系統更難理解和維護。如果所有裝置都會被用到，那就值得這麼做；如果用不到，就不值得。用不上的裝置只會擋你的路，所以，把它移開吧。
14. Temporary Field (令人迷惑的暫存欄位)
有時你會看到這樣的物件：其內某個instance變數僅為某種特定情勢而定。這樣的程式碼讓人不易理解，因為你通常認為物件在所有時候都需要它的所有變數。在變數未被使用的情況下猜測當初其設置的目的，會讓你發瘋。
15. Message Chains (過度耦合的訊息鏈)
如果你看到用戶向一個物件索求(request)另一個物件，然後再向後者索求另一個物件，然後再索求另一個物件…這就是Message Chain。程式碼中你看到的可能是一長串的getThis()或一長串暫存變數。採取這種方式，意味客戶將與搜尋過程中的航行結構(structure
of navigation)緊密耦合。一旦物件間的關係發生變化，客戶端就不得不作出相應修改。
16. Middle Man (中間轉手人)
物件的基本特徵之一就是封裝(encapsulation)－對外部世界隱藏其內部細節。封裝往往伴隨著委託(delegation)。比如說你問主管是否有時間參加一個會議，他就把這個訊息委託給他的記事簿，然後才回答你。很好，你沒必要知道這位主管到底使用傳統記事簿抑或秘書來記錄自己的約會。但是人們可能過度運用delegation。你也許會看到某個class介面有一半的函式都委託給其他class，這樣就是過度運用。這時應該直接和實責物件打交道。
原來switch這麼驚悚，我卻不知不覺跟它相處了這麼多年...
