Christopher Alexander 說過:「每個模式描述了一個在咱們周圍不斷重複發生的問題,以及該問題的解決方案的核心。這樣,你就能一次又一次地使用該方案而沒必要作重複勞動」。簡單來講就是:算法
設計模式(Design Pattern)是一套被反覆使用、多數人知曉的、通過分類編目的、代碼設計經驗的總結,使用設計模式是爲了可重用代碼、讓代碼更容易被他人理解而且保證代碼可靠性。設計模式
設計模式開發的規範,最優的方案,選擇合適的模式可大大提升開發效率,少走彎路。若是將設計模式比喻成「三十六計」,那麼每個模式都是一種計策,它爲解決某一類問題而誕生,設計模式能很好的解決一些問題。框架
經典應用框架中常見的設計模式分爲三類:學習
常見的建立型模式有:Factory 工廠模式
;Singleton 單例模式
;Prototype 原型模式
spa
常見的結構型模式有:Adapter 適配器模式
;Decorator 裝飾器模式
;Proxy 代理模式
設計
常見的行爲型模式有:Strategy 策略模式
;Template 模板模式
;Delegate 委派模式
;Observer 觀察者模式
代理
注意:在經常使用的23種設計模式中其實面沒有委派模式(Delegate)的影子,可是在Spring中委派模式確實用的比較多的一種模式,Spring MVC框架中的DispatcherServlet其實就用到了委派模式。code
單例模式:Singleton的做用是保證在應用程序中,一個類Class只有一個實例存在。並提供全局訪問。Singleton限制了實例個數,有利於GC的回收。視頻
策略模式:策略模式針對一組算法,將每個算法封裝到具備共同接口的獨立的類中,從而使得它們能夠相互替換。策略模式使得算法能夠在不影響到客戶端的狀況下發生變化。策略模式把行爲和環境分開。環境類負責維持和查詢行爲類,各類算法在具體的策略類中提供。因爲算法和環境獨立開來,算法的增減,修改都不會影響到環境和客戶端。server
原型模式:經過給出一個原型對象來指明所要建立的對象的類型,而後用複製這個原型對象的方法建立出更多同類型的對象。原始模型模式容許動態的增長或減小產品類,產品類不須要非得有任何事先肯定的等級結構,原始模型模式適用於任何的等級結構。缺點是每個類都必須配備一個克隆方法
由於Java中的提供clone()方法來實現對象的克隆,因此Prototype模式實現一會兒變得很簡單。
工廠模式:定義一個用於建立對象的接口,讓接口子類經過工廠方法決定實例化哪個類。
裝飾模式:裝飾模式以對客戶端透明的方式擴展對象的功能,是繼承關係的一個替代方案,提供比繼承更多的靈活性。動態給一個對象增長功能,這些功能能夠再動態的撤消。增長由一些基本功能的排列組合而產生的很是大量的功能。
使用Decorator的理由是:這些功能須要由用戶動態決定加入的方式和時機。Decorator提供了"即插即用"的方法,在運行期間決定什麼時候增長何種功能。
適配器模式:把一個類的接口變換成客戶端所期待的另外一種接口,從而使本來因接口緣由不匹配而沒法一塊兒工做的兩個類可以一塊兒工做。適配類能夠根據參數返還一個合適的實例給客戶端
將兩個不兼容的類糾合在一塊兒使用,屬於結構型模式,須要Adaptee(被適配者)和Adaptor(適配器)兩個身份。
爲什麼使用?
咱們常常碰到要將兩個沒有關係的類組合在一塊兒使用,第一解決方案是:修改各自類的接口,可是若是咱們沒有源代碼,或者,咱們不肯意爲了一個應用而修改各自的接口。 怎麼辦? 使用Adapter,在這兩種接口之間建立一個混合接口(混血兒)。
如何使用?
實現Adapter方式,其實"think in Java"的"類再生"一節中已經提到,有兩種方式:組合(composition)和繼承(inheritance)。
代理模式:代理模式給某一個對象提供一個代理對象,並由代理對象控制對源對象的引用。代理就是一我的或一個機構表明另外一我的或者一個機構採起行動。
某些狀況下,客戶不想或者不可以直接引用一個對象,代理對象能夠在客戶和目標對象直接起到中介的做用。客戶端分辨不出代理主題對象與真實主題對象。代理模式能夠並不知道真正的被代理對象,而僅僅持有一個被代理對象的接口,這時候代理對象不可以建立被代理對象,被代理對象必須有系統的其餘角色代爲建立並傳入。
觀察者模式:觀察者模式定義了一種一隊多的依賴關係,讓多個觀察者對象同時監聽某一個主題對象。這個主題對象在狀態上發生變化時,會通知全部觀察者對象,使他們可以自動更新本身。發佈訂閱。
模板模式:模板方法模式準備一個抽象類,將部分邏輯以具體方法以及具體構造子的形式實現,而後聲明一些抽象方法來迫使子類實現剩餘的邏輯。
不一樣的子類能夠以不一樣的方式實現這些抽象方法,從而對剩餘的邏輯有不一樣的實現。先制定一個頂級邏輯框架,而將邏輯的細節留給具體的子類去實現。
設計上的事就是這樣,想到了, 就能比較優雅的解決問題,想不到的話, 就只能使用處處修改代碼的方法比較笨拙的應對問題,還容易將項目弄的混亂。固然也建議大家看看這套關於設計模式視頻,放在羣895244712
裏面 或許會給大家一些啓發。
如今我比較慶幸當初學習了設計模式,而沒有聽其餘人的「建議」:咱們作的項目中用不到設計模式,學這個沒用。設計模式是個好東西,之後確定還要進一步的學習,而且在項目中多實踐,提高本身的設計能力。
其實設計模式並不難,難的是真正領悟它的精妙,而且能靈活的運用於平常項目的開發。