如果我們認(rèn)為模式代表一個(gè)最佳的實(shí)踐，那么反模式將代表我們已經(jīng)學(xué)到一個(gè)教訓(xùn)。受啟發(fā)于Gof的《設(shè)計(jì)模式》，Andrew Koeing在1995年的11月的C++報(bào)告大會(huì)上首次提出反模式。在Koeing的報(bào)告中，反模式有著兩種觀念:

描述對(duì)于一個(gè)特殊的問(wèn)題，提出了一個(gè)糟糕的解決方案，最終導(dǎo)致一個(gè)壞結(jié)果發(fā)生
描述如何擺脫上述解決方案并能提出一個(gè)好的解決方案

關(guān)于這個(gè)話題，Alexander寫過(guò)要在好的設(shè)計(jì)結(jié)構(gòu)和好的上下文中找到平衡是困難的:

這些筆記是關(guān)于設(shè)計(jì)的過(guò)程，這個(gè)過(guò)程發(fā)明顯示一個(gè)新的物理順序響應(yīng)功能，組織形式，物質(zhì)的東西......每一個(gè)設(shè)計(jì)問(wèn)題開(kāi)始于努力實(shí)現(xiàn)兩個(gè)實(shí)體之間的形式：?jiǎn)栴}中的形式和它的上下文。此形式是解決問(wèn)題的方法，而上下文定義了該問(wèn)題。

雖然理解設(shè)計(jì)模式很重要，但對(duì)于理解反模式也是同等重要。我們有資格知道這背后的原因。當(dāng)我們開(kāi)發(fā)一個(gè)應(yīng)用，這個(gè)工程的生命周期開(kāi)始建設(shè)一直至項(xiàng)目完成，但一旦完成后，就進(jìn)入維護(hù)階段。判斷一個(gè)解決方案的好壞要看這個(gè)團(tuán)隊(duì)在這個(gè)項(xiàng)目上投資的技術(shù)和花費(fèi)的時(shí)間。這里被認(rèn)為是好的和壞的情況下-如果應(yīng)用在錯(cuò)誤的情況下，一個(gè)“完美”的設(shè)計(jì)可能有資格作為一個(gè)反模式。

最大的挑戰(zhàn)發(fā)生于應(yīng)用進(jìn)入生產(chǎn)和維護(hù)階段。一個(gè)之前沒(méi)有開(kāi)發(fā)過(guò)這個(gè)應(yīng)用的開(kāi)發(fā)者來(lái)維護(hù)一個(gè)系統(tǒng)可能會(huì)引進(jìn)糟糕的設(shè)計(jì)。如果說(shuō)糟糕的設(shè)計(jì)是因?yàn)榉茨Ｊ剑敲磳⒃试S開(kāi)發(fā)者提前找到一種認(rèn)識(shí)到時(shí)這樣的手段，這樣就能避免一些普通錯(cuò)誤的發(fā)生，與此同時(shí)這也是設(shè)計(jì)模式給我們提供一種認(rèn)識(shí)到普通技術(shù)也是有用的方式。

反模式是一個(gè)值得為此專門編寫編寫總結(jié)文檔的糟糕設(shè)計(jì)。Javascript的反模式例子如下:

在全局上面文中定義大量污染全局命令空間的變量
在調(diào)用setTimeout和setInterval時(shí)傳遞字符串(會(huì)用eval來(lái)執(zhí)行)而不是函數(shù)。
修改Object的原型 (這是最糟糕的反模式)
使用內(nèi)聯(lián)Javascript

在本應(yīng)使用document.createElement的地方使用document.write。document.write被錯(cuò)誤的用了相當(dāng)多的年頭，它有相當(dāng)多的缺點(diǎn)，包括如果在頁(yè)面加載后執(zhí)行它可能會(huì)覆蓋我們的頁(yè)面。再有它不能工作在XHTML下，這也是另外一個(gè)我們使用像document.createElement這種對(duì)DOM友好方法的原因。

知道反模式對(duì)成功來(lái)說(shuō)很關(guān)鍵。一旦我們能識(shí)別這些反模式，我們就能夠重構(gòu)我們的代碼使項(xiàng)目的整體質(zhì)量立馬提升。

上一篇：編寫設(shè)計(jì)模式下一篇：觀察者模式