23種設計模式

關於23種設計模式的理解

         今天來全面複習一下軟件設計模式的相關知識，經過複習這些過去學過的知識，來更好的理解咱們要學的軟件架構方面的知識。

         首先咱們先了解一下模式這個詞吧，模式最先起源於建築業，它的定義包含三個方面：Context(模式適用的前提條件)、Problem(在特定條件下須要解決的目標問題)、Solution(對目標問題各類關係的描述)。最後總結出的定義：模式是在特定環境中解決問題的一種方案。模式描述瞭解決問題的核心，經過這種方式，咱們無需再作一樣的工做，只需根據模式去複用他們，就能夠完成相應的任務。

         那麼軟件設計模式又是什麼呢？軟件設計模式被反覆使用、多數人知曉的、通過分類編目的、代碼設計經驗的總結，使用軟件設計模式是爲了可重用代碼、讓代碼更容易被他人理解、保證代碼的可靠性。而咱們根據其目的又能夠將軟件分爲：建立型、結構型和行爲型三種。

那麼咱們首先看一下建立型的各類設計模式。

  簡單工廠模式

 

 

         咱們能夠看到簡單工廠模式是建立了一個抽象的產品類，而後你須要具體建立什麼產品，只須要在靜態的工廠方法類中傳遞正確的參數，咱們工廠類就能根據相應的參數創造出正確的產品，採用簡單工廠方法的模式，咱們沒必要再判斷出要建立什麼類型的產品後，寫一大堆的代碼，而是隻要new出相應的產品便可，下降了系統的耦合性，使工廠方法和產品方法的修改都變得更加容易。

 

  工廠方法模式

 

 

咱們能夠看到工廠方法模式是對簡單工廠方法模式的一種完善，在簡單工廠方法模式中，若是有新的產品須要加入系統中時，就必需要編寫相應的邏輯方法，而這違背了設計模式中的「開閉原則」，而工廠方法模式正解決了這一問題，它將工廠類抽象出來，當須要建立產品時，去交給他的子工廠類去建立，這樣當須要建立新產品時，只須要建立一個新的產品類和子工廠類就好，知足了開閉原則。

 

  抽象工廠模式

 

 

抽象工廠模式是爲了處理工廠所須要生產的產品並非一個簡單的對象，而是處理生產多個位於不一樣產品等級結構中屬於不一樣類型的具體產品。好比生產電視機和空調，而電視機和空調又能夠分爲Hair和TCL的，相同品牌的電器被稱爲產品族，相同類型的電器爲產品等級結構，他必須把不一樣品牌的電器，創造出不一樣的工廠來建立相應的產品。

 

  建造者模式

 

 

 

在咱們的現實生活中，咱們常常要建造一個複雜的對象，相似於汽車，咱們客戶並不關心其中有什麼組件和他們的裝配細節，而關心的一輛完整的汽車，而在咱們的軟件中有時也有一些複雜的對象，咱們不須要知道里面構建的細節，只須要返回一個完整的對象便可，這時就須要建造者模式。

 

  原型模式

 

 

 

原形模式就是根據一個對象，來複製出多個與原來對象如出一轍的對象，其中根據其成員對象是否也克隆分爲深克隆和淺克隆。

 

  單例模式

 

 

 

單例模式是爲了確保某一個類中只有一個實例，而且這個類會自行實例化這個實例，而且向整個系統提供這個實例。單例模式用處挺大的，像j2ee中那些鏈接數據庫的操做，很是佔用內存，若是常常開啓新的實例來鏈接的話，那麼系統會吃不消，這時候單例模式就是一個不錯的選擇了。

 

 

接下來是結構型的設計模式，結構型設計模式關注的是經過關聯關係使得一個類中去定義另外一個類的實例對象

  適配器模式

 

 

適配器就像咱們的電腦充電器，能夠經過它使咱們的電腦充上電。適配器模式能夠理解爲經過一個接口使接口不兼容的那些類能夠同時工做，好比咱們能夠經過一個轉化接口使機器人類能夠模仿人的行爲。

 

  橋接模式

 

 

 

就是使抽象和實現分開，使他們能夠各自獨立的發生變化，好比畫筆的大小和顏色，若是咱們簡單的將他們組合去一個個實例化，那就太複雜了，若是採用橋接模式的話，咱們只需將抽象類中的相應的實現取出來就行了。

 

 

  組合模式

 

 

組合模式就是將多個對象以樹形結構表示出來，其中容器對象類和容器之間有一個聚合關聯關係，經過這個關聯，可使容器對象包含葉子，也能夠包含容器對象，以此實現遞歸組合，造成一個樹形結構。典型的表明就是文件夾和文件的關係。

 

  裝飾模式

 

 

 

裝飾模式，就如其名字，其目的就是爲了動態的給一個對象增長一些額外的職責，就像給一個照片加上不一樣類型的相框同樣，裝飾模式是在一個已有的構件類上進行相應的裝飾，好比變形金剛的例子，剛開始是一輛汽車，進行裝飾以後能夠變成機器人。

 

 

  外觀模式

 

 

 

外觀模式，就像網站的首頁同樣，一個網站包含許多子模塊，若是一個用戶每次想進入相應的子模塊，都要本身輸入相應子模塊的地址，那就太麻煩了，而首頁就很好的解決了這一問題，用戶只需記住一個首頁的網址，而後在進行選擇就行了。這就是外觀模式，經過一組接口來爲子系統提供一個一致性的界面，這個接口使子系統更加容易使用。

 

 

  享元模式

 

 

 

享元模式是一個爲了提升系統的性能的設計模式，在系統運行的過程當中，有許多對象都是相似的，他們在被應用的時候狀態很小，所以咱們能夠創建一個享元類保存這個重用率很高的類，當用戶須要時首先從享元類中檢查一下有沒有所須要的類，若是有的話，就不須要從新建立了，就是經過這樣的方法來提升系統的效率。

 

 

  代理模式

 

 

 

代理模式，相似於咱們買房時候的房屋代理，有的時候咱們不能咱們想要訪問的對象（如房主）進行直接的溝通，這時候咱們就須要一個代理，代理模式就是解決這樣問題的一個模式，像spring中AOP就是典型的代理模式，代理模式，使咱們經過代理間接的訪問一個對象，對其進行操做。

 

最後是行爲模式的內容，行爲模式不只關注類和對象的結構，重點關注他們之間的相互做用。

 

  職責鏈模式

 

 

 

         職責鏈模式的目的主要是避免請求發送者與接收者耦合在一塊兒，讓多個對象都有可能接收到請求，將這些對象鏈成一條鏈，並沿着這條鏈傳遞請求。職責鏈模式由每個對象對其下家的引用連成一條鏈。例如咱們的請假條，首先交給輔導員處理，輔導員處理不了，交給系主任處理，系主任處理不了交給院長，就是這麼一層層的造成一條鏈。

 

  命令模式

 

 

命令模式主要是解決那種咱們須要向系統中的某些對象發送請求，但殊不知道請求的接收者具體是誰，也不知道被請求的操做具體是哪一個，咱們只需在程序具體運行時指定具體的請求接收者便可。好比電視遙控器的操做，咱們並不知道，具體執行開機、關機、換頻道的具體對象是哪一個，可是咱們只需用遙控器發送相關的命令便可。

 

 

  解釋器模式

 

 

 

若是在系統中某一特定類型的問題發生的頻率很高，此時能夠考慮將這些問題實例表述成爲一個語言中的句子，所以能夠構成一個解釋器，改解釋器經過這些句子來解釋這些問題。這一模式主要應用於面嚮對象語言開發的編譯器中。

 

  迭代器模式

 

 

 

 

迭代器模式主要是提供一種方法來訪問聚合對象，而不用暴露這個對象的內部表示。好比像java中的集合類，咱們就能夠經過迭代器模式進行遍歷，但又不須要去了解其內部結構。

 

  中介者模式

 

 

經過一個對象來封裝一系列的對象交互，中介者使用對象不須要顯示地相互引用，能夠下降耦合性，使他們能夠獨立的改變他們之間的交互。這個模式就像咱們的qq羣同樣，有了qq羣，咱們想和多我的聊天，就不用一個個的和他們進行聊天，只要經過羣就能夠實現多人同時進行聊天。

 

  備忘錄模式

 

 

 

備忘錄模式，咱們對軟件進行操做的時候，不免會犯一些錯誤，這時咱們就須要利用咱們的備忘錄模式來保存每一次系統操做的狀態，一旦咱們進行錯誤的操做，咱們把以前的狀態取出就能夠回到之前的狀態。

 

  觀察者模式

 

 

觀察者模式，定義了對象之間的一種一對多依賴關係，它使得當每個對象狀態發生改變時，其相關依賴對象皆獲得通知而且自動更新。他的原理就像股票和股民同樣，當股票上漲時，股民就會興奮；當股票下跌時，股民就會傷心失望。

 

  狀態模式

 

 

 

不少狀況下，一個對象的行爲取決於一個或者多個動態變化的屬性，這樣的屬性就叫作狀態，而每每當對象的狀態改變時，他的行爲也會發生相應的變化，如當一我的開心時，他就可能唱歌、請客吃飯；傷心時，就可能本身一我的默默的悲傷，這就是狀態的改變引發行爲上的變化，而狀態模式正是用來描述這樣行爲的模式。

 

  策略模式

 

 

在多數狀況下，咱們實現某個目標的途徑不止一條，例如人們外出旅行的出行方式。咱們能夠根據本身能承受的經濟限度，選擇不一樣的出行方法。而策略模式正是將解決問題的不一樣方法封裝起來，使他們能夠相互替換，而具體選擇哪一個就須要根據實際狀況具體而定了。

 

  模板方法模式

 

 

 

在生活中，咱們可能都經歷過這種狀況，好比請客吃飯，咱們都會經歷點菜，吃東西和買單幾個步驟，而到底吃什麼則由用戶本身決定。模板方法模式就是描述這樣一種狀況的模式，它先將算法的骨架寫出來，而將一些用戶要決定的事情推遲到子類中決定。

 

  訪問者模式

 

 

 

訪問者模式，表示一個做用於某對象結構中的各元素的操做，它是咱們能夠在不改變各元素的類的前提下定義做用於這些元素的新操做。好比對於購物車中的水果和圖書，收銀員的操做是計算價格，進行收款，而顧客的操做則是進行付款。