圖1：簡化的Singleton模式
通過將圖1中簡化的模式示例與QuoteManager源代碼進行比較，闡明了模式（通用問題-解決方案對）和模式應用程序（針對非常具體的問題的具體解決方案）之間的區別。模式級別的解決方案是多個類之間簡單但極其順暢的協作。模式中的通用協作專門適用于QuoteManager類，提供了用來控制報價應用程序中實例化的機制。顯然，您可以稍微修改一下某種模式以滿足局部的特定要求，所以同一種模式可以應用于無數個應用程序。
所編寫的模式提供了一種記錄簡單且經過證實的機制的有效方法。模式是以特定格式編寫的，這一點對于裝載復雜思想的容器非常有用。這些模式在被記載和起名之前，就早已存在于開發人員的大腦及其代碼中。
位于不同級別的模式
模式存在于多個不同的抽象級別中�？紤]另一個示例（這次所處的抽象級別比源代碼要高一級）：
您要設計一個基于Web的報價應用程序，其中包含大量業務和表示邏輯，這些邏輯反過來依賴大量平臺軟件組件來提供適當的執行環境。如何在高級別組織系統以使其在具有靈活、松耦合性的同時仍具有高內聚性？
此問題的解決方案之一涉及到按一系列層來組織系統，每層包含大致位于同一抽象級別的元素。隨后，確定每一層中的依賴性，并確定采用嚴格還是寬松的分層策略。接著，決定是打算創建自定義的分層方案，還是采用以前由其他人記錄的分層方案。在本例中，假設您決定使用眾所周知的分層策略：表示、業務邏輯和數據訪問各占一層。圖2顯示了分層方案的可能外觀。
如果您總是按這種方式設計系統，說明您已經在不依賴于任何廣義模式的情況下使用該模式。即便如此，您還可能因多種原因而希望了解支撐這種設計方法的模式。您可能迫切想知道為何經常以這種方式構建系統，或者可能在尋找更理想的方法來解決此模式不能完全解決的問題。使用層作為高級別組織方法是Layers（層）模式[Buschmann96][3]中描述的完善模式。圖3顯示了該模式的簡化版本。
圖3：簡化的Layers模式 這個簡單的應用程序組織策略有助于解決軟件開發中面臨的兩個挑戰：依存關系的管理和對可交換組件的需求。如果在構建應用程序時沒有一個考慮周全的依存關系管理策略，會導致組件易損壞且不牢靠，從而導致對它們進行維護、擴展和替代時存在較大的困難，而且成本較高。Layers模式中的工作機制比Singleton中的工作機制更精細。對于Layers，首次協作是在設計時發生在類之間，這是由于分層組織將對更改源代碼所帶來的影響局部化，從而防止所做的更改貫穿到整個系統。第二次協作發生在運行時：某層中相對獨立的組件變得可與其他組件交換，再一次使系統其余部分不受影響。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
