Java應用中的反模式開發介紹

2019-11-18 11:14:40

字體：大中小

來源：轉載

供稿：網友

設計模式（design pattern）為我們提供了一條途徑，使我們能夠進行簡潔明了地溝通，以得到期望的軟件經驗；反模式與此類似，只不過它是用于溝通那些不合乎需求的經驗的--下面是一些可以幫助你起步的通常碰到的反模式。

　　反模式是一種典型的、糟糕的設計；換句話說，它是設計模式的對立面--設計模式提出的是良好的設計。在某種意義上講，反模式表現的是糟糕的解決方案，它讓相關人員更輕易理解根本的問題和問題之間的因果關系。盡管了解設計模式很重要，但是我相信理解反模式也是一樣重要的--我們應該理解反模式。

　　我們來證實一下自己的觀點。軟件世界是圍繞應用程序的維護來"運行"的。當然，每個軟件產品的生命周期都是從構造的時候開始的，但是在開始大量生產以后，就需要維護了。根據開發小組的技巧，產品可能擁有"良好的"或"糟糕的"設計，其中的"良好"或"糟糕"是對應于一定的環境中，因為一種良好的設計假如應用在錯誤的環境中也可能成為一種反模式。例如，在單應用程序（single-application）服務器環境中使用Singleton是恰當的，但是在群集應用程序（clustered-application）服務器環境中，假如它沒有被正確地處理好，就會產生很多問題。與正面的設計模式形成對比的是，反模式引出的是負面的解決方案或以前的方法（去年的解決方案在今年就可能是反模式了），這可能是由于小組成員缺乏足夠的信息，或者在實現設計或解決問題方面作出了糟糕的判定。

　　在產品開始生產并進入維護模式之后，真正的問題才開始顯現。一個從未參與產品開發的從事維護工作的開發者可能給項目引入"糟糕的設計"元素。但是假如這種糟糕的實踐被編寫為反模式"法典"，就可以預先提醒開發者，避免最普通的缺陷，就像設計模式"法典"為開發者提供了識別出普通的有用的技術途徑一樣。根據這種邏輯，反模式是一種值得我們記載的普遍存在的糟糕的設計。

　　當我們使用J2EE等技術的時候，這種方法的優勢尤其明顯。J2EE的初始設計哲學強調簡單性，但是它的復雜程度已經變得難以置信了。在這種復雜的環境中，模式和反模式同時為軟件經理、架構師、設計師和開發者提供了通用的"詞典"。

　　無論在構造模式還是在維護模式中，為了獲得成功，我們理解反模式都是必要的。在反模式被記錄下來之后，開發者一般可以熟悉到這些負面的模式，以根除糟糕的設計，改善軟件。

　　本文從軟件架構和開發的角度來談論反模式。接著它提出了在J2EE應用程序的大多數通用層次（用戶界面、永續性、EJB等）中普遍存在的反模式。它的全部目標是為這些反模式提供背景知識，并為避免這些問題提供建議。

　　表1列舉了本文中討論的三種普遍的設計、開發和架構的反模式。

　　表1：普遍的反模式

領域普通的反模式設計編寫具體的類而不是接口在代碼中耦合了邏輯（例如日志記錄、安全性和緩沖）開發Golden Hammer（金錘）Input Kludge（輸入雜亂）架構Reinvent the wheel（重新發明輪子）Vendor lock-in（廠商的鎖定）
　　普遍的反模式

　　上表列舉的反模式跨越了廣闊的開發者領域。

　　編寫具體的類而不是接口

　　這是一條重要的設計原則，但是卻經常被破壞--編寫接口而不是具體的類可以提供數不清的優點！你不會被"捆綁"在使用某種特定的實現上，同時可以在運行時改變行為。"接口"這個術語意味著要么是一個java接口，要么是一個抽象類。只要你應用多態性（polymorphism），應用程序的行為就不會被"鎖定"在特定的代碼中。請注重，當你知道其行為不會改變的時候，這條規則就不適用了。

　　編寫一個實現的例子如下所示：

Dog animal = new Dog();
animal.bark();
　　作為對比，編寫一個接口的例子是：

Animal animal = getAnimal(Dog.class);
animal.makeNoise();
　　上面的兩個例子有兩個不同點。第二個版本使用制造廠（factory）方法來動態地獲取Dog類的實例。同時，第二個版本泛化（generalize）了bark()方法，它是makeNoise()方法的Dog具體實現，而任何動物都可以實現這個方法。下面的代碼顯示了AnimalFactory類的getAnimal()方法和Dog類，它舉例說明了一個特定的Animal實現。

getAnimal(Class c)
{
　if (c == Dog.class)
　　return new Dog();
　　// 此處測試其它類型
}

class Dog
{
　makeNoise()
　{
　　bark();
　}
}
　　過多的耦合

　　我們在編寫代碼的時候，需要緊記一條基本的軟件觀念--一般情況下，耦合越少越好。例如，你編寫一段代碼來執行某項事務，那么它就應該只執行該項事務，這樣代碼才整潔、輕易閱讀、易于維護。但是有些東西是不可避免的，例如日志記錄、安全性和緩沖等方面可能需要耦合。幸運的是，有些辦法可以避免這種情況的發生。其中的一種技術--面向方面的編程（AOP）通過在編譯時（compile time）給應用程序注入方面（aspect）的行為，為達到這個目的提供了一條靈巧的途徑。

　　開發：金錘反模式

　　過多地或者強制性地使用某種技術或模式可能會導致金錘反模式。精通特定技術或軟件的團體或個人傾向于在特性相似的其它項目中也使用類似的技術--即使其它的技術更適合那種情況。他們把不熟悉當作是冒險。此外，計劃和評估熟悉的技術也更加簡單。通過書本、培訓和用戶組（例如Java用戶組）的形式來擴充開發者的知識對避免這種反模式非常有益。

　　輸入信息雜亂

　　軟件錯誤地處理簡單的用戶輸入信息就會形成輸入信息雜亂。例如，Web站點讓用戶輸入ID和密碼來登錄，那么它接受的輸入內容就應該僅僅是可用作ID和密碼的字符。假如該站點的邏輯拒絕了無效的輸入，那么它在這個方面就是安全的，但是假如它沒有拒絕這些無效的輸入，就可能出現不可預料的結果。輸入信息雜亂很輕易被最終用戶發現，但是在開發者進行單元測試的時候很難發現。

　　你可以使用怪用測試（monkey test）來檢測輸入信息雜亂的問題。雖然它超出了本文討論的范圍，但是它的確在沒有任何"典型用戶"偏好的情況下，實現了隨機的自動化測試。

上一篇：sunTechnicalTrainingNOTE

下一篇：基礎應用:javaweb三層架構配置入門