常用設計模式

黎克特制代換原則(liskov substitution principle lsp)物件導向設計的基本原則之一。黎克特制代換原則中說，任何基類可以出現的地方，子類一定可以出現。 lsp是繼承復用的基石，只有當衍生類可以替換掉基類，軟體單位的功能不受到影響時，基類才能真正被復用，而衍生類也能夠在基類的基礎上增加新的行為。黎克特制代換原則是對「開-閉」原則的補充。實現「開-閉」原則的關鍵步驟就是抽象化。而基類與子類的繼承關係就是抽象化的具體實現，所以黎克特制代換原則是對實現抽象化的具體步驟的規範。—— from baidu 百科

這個是開閉原則的基礎，具體內容：針對對介面程式設計，依賴於抽象而不依賴於具體。

使用多個隔離的介面，比使用單個介面要好。還是乙個降低類之間的耦合度的意思，從這兒我們看出，其實設計模式就是乙個軟體的設計思想，從大型軟體架構出發，為了公升級和維護方便。所以上文中多次出現：降低依賴，降低耦合。

乙個實體應當盡量少的與其他實體之間發生相互作用，使得系統功能模組相對獨立。

原則是盡量使用合成/聚合的方式，而不是使用繼承。

總體來說設計模式分為三大類：

建立型模式，共五種：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。

結構型模式，共七種：介面卡模式、裝飾器模式、**模式、外觀模式、橋接模式、組合模式、享元模式。

行為型模式，共十一種：策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、直譯器模式。

就是建立乙個工廠類，對實現了同一介面的一些類進行例項的建立。首先看下關係圖

餓漢模式：餓漢式的特點是應用中尚未需要用到此單一例項的時候即先例項化

class

hungrysingleton //防止外部建立例項

private
static hungrysingleton singleton=new
hungrysingleton(); //類載入的時候初始化好例項（正常情況類只會載入一次）
public
static
hungrysingleton getinstance() } //需要的時候獲取例項

執行緒安全的懶漢模式

class
locksingleton
public
static
locksingleton getinstance()}}
return
singleton;}}

執行緒安全的改進型懶漢式（內部靜態類）

特點：載入時不會初始化靜態變數instance，因為沒有主動使用，達到lazy load。如果多個執行緒同時呼叫getinstance方法，在初始化靜態變數

static singleton singleton時，執行緒會先嘗試獲取類物件的鎖。只有獲得類物件的鎖線程，才能構造

singleton例項。這樣保證了執行緒安全性。

package
com.qqyumidi;
public
class
singleton 
//私有化建構函式
private
singleton() 
public
static
singleton getinstance() 
}

介面卡模式將某個類的介面轉換成客戶端期望的另乙個介面表示，目的是消除由於介面不匹配所造成的類的相容性問題。主要分為三類：類的介面卡模式、物件的介面卡模式、介面的介面卡模式。首先，我們來看看類的介面卡模式，先看類圖：

物件的介面卡模式

基本思路和類的介面卡模式相同，只是將adapter類作修改，這次不繼承source類，而是持有source類的例項，以達到解決相容性的問題。看圖：

第三種介面卡模式是介面的介面卡模式，介面的介面卡是這樣的：有時我們寫的乙個介面中有多個抽象方法，當我們寫該介面的實現類時，必須實現該介面的所有方法，這明顯有時比較浪費，因為並不是所有的方法都是我們需要的，有時只需要某一些，此處為了解決這個問題，我們引入了介面的介面卡模式，借助於乙個抽象類，該抽象類實現了該介面，實現了所有的方法，而我們不和原始的介面打交道，只和該抽象類取得聯絡，所以我們寫乙個類，繼承該抽象類，重寫我們需要的方法就行。看一下類圖：

**模式就是多乙個**類出來，替原物件進行一些操作，比如我們在租房子的時候回去找中介，為什麼呢？因為你對該地區房屋的資訊掌握的不夠全面，希望找乙個更熟悉的人去幫你做，此處的**就是這個意思

橋接模式就是把事物和其具體實現分開，使他們可以各自獨立的變化。橋接的用意是：將抽象化與實現化解耦，使得二者可以獨立變化，像我們常用的jdbc橋drivermanager一樣，jdbc進行連線資料庫的時候，在各個資料庫之間進行切換，基本不需要動太多的**，甚至絲毫不用動，原因就是jdbc提供統一介面，每個資料庫提供各自的實現，用乙個叫做資料庫驅動的程式來橋接就行了。我們來看看關係圖：

策略模式定義了一系列演算法，並將每個演算法封裝起來，使他們可以相互替換，且演算法的變化不會影響到使用演算法的客戶。需要設計乙個介面，為一系列實現類提供統一的方法，多個實現類實現該介面，設計乙個抽象類（可有可無，屬於輔助類），提供輔助函式，關係圖如下：

包括這個模式在內的接下來的四個模式，都是類和類之間的關係，不涉及到繼承，學的時候應該記得歸納，記得本文最開始的那個圖。觀察者模式很好理解，類似於郵件訂閱和rss訂閱，當我們瀏覽一些部落格或wiki時，經常會看到rss圖示，就這的意思是，當你訂閱了該文章，如果後續有更新，會及時通知你。其實，簡單來講就一句話：當乙個物件變化時，其它依賴該物件的物件都會收到通知，並且隨著變化！物件之間是一種一對多的關係。先來看看關係圖：

常用設計模式

常用設計模式

常用設計模式

常用設計模式

相關推薦