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

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

2。味道：控件/繪制器存在狀態(tài)。
有人認為Motif和Windows已經(jīng)差別很大了，有沒有想過它們和IBM收銀機上的字符界面差別有多大呢？既然差別這么大的繪制器仍然存在相同的復(fù)雜了（有時是很復(fù)雜的）狀態(tài)，那我們?yōu)槭裁床话阉鼈僥xtract出來而要讓它們?nèi)哂嗄兀?br> 典型重構(gòu)思路：視圖的模型。
視圖有視圖的模型，并不是MVC中的模型，這種方式就是Swing的基礎(chǔ)。

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

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

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

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

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

做軟件的泡泡