經常使用設計模式的應用場景

1. 單例模式：
      容許自由建立每一個類沒有實際意義，還有可能形成系統性能降低。優點：減小建立java實例帶來的系統開銷，便於系統跟蹤某個實例的生命週期，實例狀態等。

2. 工廠模式：
     工廠模式又分簡單工廠模式，抽象工廠模式。使用簡單工廠模式的優點是：讓對象的調用者和對象建立過程分離，當對象調用者須要對象時，直接向工廠請求便可。從而避免了對象的調用者與對象的實現類以硬編碼方式耦合，以提升系統的可維護性、可擴展性。工廠模式也有一個小小的缺陷：當產品修改時，工廠類也要作相應的修改。
   實際用例:，應該對Spring IoC容器感到迷惑：它究竟是簡單工廠？仍是抽象工廠？實際上，筆者傾向於認爲Spring IoC容器是抽象工廠，由於Sping IoC容器能夠包括萬象，它不只能夠管理普通Bean實例，也可管理工廠實例。
3.代理模式：
     當客戶端代碼須要調用某個對象時，客戶端實際上也不關心是否準確獲得該對象，它只要一個能提供該功能的對象便可，此時咱們就可返回該對象的代理（Proxy）。
      實際用例：
看到此處，相信讀者應該對Spring的AOP框架有點感受了：當Spring容器中的被代理Bean實現了一個或多個接口時，Spring所建立的AOP代理就是這種動態代理。Spring AOP與此示例應用的區別在哪裏呢？Spring AOP更靈活，當Sping定義InvocationHandler類的invoke()時，它並無以硬編碼方式決定調用哪些攔截器，而是經過配置文件來決定在invoke()方法中要調用哪些攔截器，這就實現了更完全的解耦——當程序須要爲目標對象擴展新功能時，根本無須改變Java代理，只須要在配置文件中增長更多的攔截器配置便可。
    
4. 命令模式：
     某個方法須要完成某一個功能，完成這個功能的大部分步驟已經肯定了，但可能有少許具體步驟沒法肯定，必須等到執行該方法時才能夠肯定。具體一點：假設有個方法須要遍歷某個數組的數組元素，但沒法肯定在遍歷數組元素時如何處理這些元素，須要在調用該方法時指定具體的處理行爲.
  例子：HibernateCallback接口
     
5. 策略模式：
    封裝系列的算法
    應用實例:Hibernate的Dialect會有一點感受了，這個Dialect類表明各數據庫方言的抽象父類，但不一樣數據庫的持久化訪問可能存在一些差異，尤爲在分頁算法上存在較大的差別，Dialect不一樣子類就表明了一種特定的數據庫訪問策略。爲了讓客戶端代碼與具體的數據庫、具體的Dialect實現類分離，Hibernate須要在hibernate.cfg.xml文件中指定應用所使用的Dialect子類。
與此相似的是，Spring的Resource接口也是一個典型的策略接口，不一樣的實現類表明了不一樣的資源訪問策略。固然Spring能夠很是「智能」地選擇合適的Resource實現類，一般來講，Spring能夠根據前綴來決定使用合適的Resource實現類；還可根據ApplicationContext的實現類來決定使用合適的Resource實現類。具體請參考本書8.3節介紹。

6. 門面模式：
     着系統的不斷改進和開發，它們會變得愈來愈複雜，系統會生成大量的類，這使得程序流程更難被理解。門面模式可爲這些類提供一個簡化的接口，從而簡化訪問這些類的複雜性，有時這種簡化可能下降訪問這些底層類的靈活性，但除了要求特別苛刻的客戶端以外，它一般均可以提供所需的所有功能，固然，那些苛刻的用戶仍然能夠直接訪問底層的類和方法。
     實例：咱們能夠認爲HibernateTemplate是SessionFactory、Session、Query等類的門面，當客戶端程序須要進行持久化查詢時，程序無須調用這些類，而是直接調用HibernateTemplate門面類的方法便可。
     
7.橋接模式：
     因爲實際的須要，某個類具備兩個或兩個以上的維度變化，若是隻是使用繼承將沒法實現這種須要，或者使得設計變得至關臃腫。
      實際應用Dao
     
8. 觀察者模式
    觀察者模式定義了對象間的一對多依賴關係，讓一個或多個觀察者對象觀察一個主題對象。當主題對象的狀態發生變化時，系統能通知全部的依賴於此對象的觀察者對象，從而使得觀察者對象可以自動更新。
   實際用例：jms1. 這裏是列表文本