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

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

2。味道：控件/繪制器存在狀態(tài)。
有人認(rèn)為Motif和Windows已經(jīng)差別很大了，有沒有想過它們和IBM收銀機(jī)上的字符界面差別有多大呢？既然差別這么大的繪制器仍然存在相同的復(fù)雜了（有時(shí)是很復(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)事件，鍵盤事件，或某個(gè)控件的事件，事件翻譯器把低級(jí)事件翻譯為高級(jí)事件，再把高級(jí)事件包裝成請(qǐng)求，請(qǐng)求被傳遞給一個(gè)根控制器。

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

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

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

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

做軟件的泡泡