下面介紹幾種具有壞味道的代碼結構，其中很多經驗學習自Eclipse，與Martin Fowler不同的是，我找到的幾種壞味道都存在于設計理念之中，而不是缺乏設計模式的抽象，也不是未重構的代碼。先別急著反駁，也別急著嗤之以鼻，先想 想這些設計理念的優點，看看是不是微不足道，再看看這些理念的缺點，是不是有可能鑄成大錯，作者還給出了去掉這些壞味道的某個思路，即作者自己的思路，僅 供參考。最后，別忘了想想自己手中的軟件的設計，看看會不會遇到其中的熟面孔啊。。。。。

1。味道：控件耦合。
“如果第一個復選框被選中，那么下面的文本域全部失效。”通過這種方式表述的效果在軟件開發中經常遇到，很多人稱之為“界面邏輯”，想想看，界面邏輯真的可以直接變成代碼嗎？
典型重構思路：有限狀態機。
狀態與控件屬性集一一對應，控件屬性被改變時，狀態機收到事件，檢查狀態是否發生了遷移，如果是則向控件屬性集的控制器發出狀態遷移事件，控制器批量改變控件狀態。

2。味道：控件/繪制器存在狀態。
有人認為Motif和Windows已經差別很大了，有沒有想過它們和IBM收銀機上的字符界面差別有多大呢？既然差別這么大的繪制器仍然存在相同的復雜了（有時是很復雜的）狀態，那我們為什么不把它們extract出來而要讓它們冗余呢？
典型重構思路：視圖的模型。
視圖有視圖的模型，并不是MVC中的模型，這種方式就是Swing的基礎。

3。味道：視圖發出有意義的事件。
什么？你的意思是視圖應該發出無意義的事件咯？不是這樣嗎？視圖應該不了解任何業務邏輯，也不應該了解任何界面邏輯，如果界面邏輯真的存在的話。
典型重構思路：事件翻譯器。
視圖發出無意義的事件，比如鼠標事件，鍵盤事件，或某個控件的事件，事件翻譯器把低級事件翻譯為高級事件，再把高級事件包裝成請求，請求被傳遞給一個根控制器。

4。味道：動作/命令知道自己的形象。
很多時候，一個Action或者一個Command都知道自己叫什么名字，能不能被禁用，有沒有被禁用，圖標如何，甚至還知道及時幫助的字符串，執行需要什么條件，返回什么結果等等，如果這么做的話Action和Command就有了自己的視圖狀態，發出了第2種味道。
典型重構思路：動作代理。
重磅的工作交給代理完成，動作/命令只是一個視圖的模型罷了。在UI系統裝載之初，動作/命令被裝載并繪制在界面上，直到用戶點擊或觸發了這個動作/命令，它的代理才被調入并開始工作。

5。味道：模型知道自己的每一個用處。
有n種視圖對應同一個模型，比如對一個網頁制作工具來說，一個html文件至少有三種視圖：代碼、設計、預覽。如果模型同時能滿足這三種視圖的需求的話，這個模型就太重磅了，而且還不好添加一種新視圖。比如Dreamwaver的代碼/設計頁面。
典型重構思路1：一個模型，多個維度。
如果一個模型擁有n個維度，則n個對象，就可以確定一個事實，n-1個對象就可以得到一個線性聚集，n-2個對象就可以得到一個二維表。每個維度就是一組Interface,而事實的類型，其實是不可見的，（內部的巨大類型），只能通過維度確定事實，再提取事實的屬性。
典型重構思路2：適配器模式。
模型首先實現最必要的接口，然后當需要模型實現某個非必要接口時，模型會主動或被動的適配為一個滿足需求接口的“意外”對象。

6。味道：控制器變成顧問類。
有些人認為我們的社會需要復合型的人才，因為每個人都要具備管理的能力，控制器也要懂管理，它要負責視圖和模型之間的交互。但是仔細想想，如果被模型以外的對象知道了業務邏輯的話，那模型還可以替換嗎？
典型重構思路：控制器標準化。
控制器將請求包裝為命令，并將命令交給命令堆棧執行。控制器并不了解模型，模型只能由模型自己了解，控制器也不知道領域邏輯，它只是做一些機械的翻譯工作，并利用視圖和模型提供的（互補相關）的素材，創建和模型相關的命令。

7。味道：模型變成無所不知博士。
在沒有發生上面六種情況的時候，千萬不要大意啊，你很有可能發生了這一種情況，恰恰是因為控制器和視圖都不知道業務邏輯，模型才有可能發展為Dr.Know。但是視圖往往是樹狀結構的啊，它怎么和Dr.Know合作呢？通過代理？還是Facade？
典型重構思路：復雜模型結構（樹狀、圖狀、知識/操作分離）。
如果有可能，模型也是樹狀的，可以和視圖一一對應；如果這一點做不到，不要緊，可以把大模型劃分成輕量小板塊，或者迭代子，再用關系對象解釋它們之間的關系；如果還不行，那總得做到知識和操作分離吧。。。。。。。

做軟件的泡泡