設計模式彙總篇-兄弟,該學點設計模式了!

總序

這篇文章是對整個設計模式彙總篇,繪製了各種設計模式的UML類圖,補充之前分享的篇幅中沒有UML類圖,方便學習和查看,文中的大部分文字敘述,在開篇寫設計模式系列已經有存在。文章最後提供了設計模式的源碼下載地址,有需要的可以直接下載使用,源碼在windows下使用VS2017編譯通過,可以使用VS系列直接創建工程編譯,採用純C++編寫,也可以移植到linux平臺編譯。

一、設計模式簡述

設計模式是用來在一個特定的環境中解決某一個問題的方案,它是一套被反覆使用、經過大量驗證、經過分類設計的編碼經驗的總結,使用設計模式可以實現代碼的可複用性、讓代碼更易被人理解、保證代碼的質量和可靠性。

它就像軟件工程的基石,像一座大廈的鋼架一樣,要成爲一個真正地編程高手,學會設計模式是必修的內功。

二、設計模式的原則

在這裏插入圖片描述

1、開放封閉原則

類的改動是通過增加代碼進行的,而不是修改源代碼。

2、單一職責原則

類的職責要單一,對外只提供一種功能,而引起類變化的原因都應該只有一個。

3、依賴倒置原則

依賴於抽象 (接口 ),不要依賴具體的實現 (類),也就是針對接口編程。

4、 接口隔離原則

不應該強迫客戶的程序依賴他們不需要的接口方法; 一個接口應該只提供一種對外功能,不應該把所有操作都封裝到一個接口中去。

5、里氏替換原則

任何抽象類出現的地方都可以用他的實現類進行替換;實際就是虛擬機制, 語言級別實現面向對象功能。

6、優先組合而不繼承原則

如果使用繼承,會導致父類的任何變換都可能影響到子類的行爲;如果使用對象組合,就降低了這種依賴關係。

7、迪米特法則

一個對象應當對其他對象儘可能少的瞭解, 從而降低各個對象之間的耦合, 提高系統的可維護性。

三、設計模式的分類

Gang of Four四位大神將設計模式分爲三大類,23種設計模式。
在這裏插入圖片描述

1、三大類

創建型設計模式:和對象的創建有關,涉及到對象的實例化方式。
結構型設計模式:描述的是如何組合類以及獲得更好的結構。
行爲型設計模式:用來對類或者對象怎麼交互和怎麼分配職責進行描述。

2、23種設計模式簡述和UML類圖

創建型有5種設計模式:
1》單例模式( Singleton Pattern ):一個類僅有一個實例,並且只提供一個訪問它的全局對外口。
在這裏插入圖片描述
2》工廠模式( Factory Method Pattern ):定義一個創建產品對象的工廠接口,將實際創建工作放到到子類中。
在這裏插入圖片描述
3》抽象工廠模式( Abstract Factory Pattern ):定義一個創建一系列相關或者相互依賴的接口,而無需指定它們具體的類。
在這裏插入圖片描述
4》建造者模式( Builder Pattern ):將一個複雜的構建與其表示相分離,使得同樣的構建過程可以創建不同的表示。
在這裏插入圖片描述
5》原型模式( Prototype Pattern ):用原型實例指定創建對象的種類,並且通過拷貝這些原型創建新的對象。
在這裏插入圖片描述

0》簡單工廠模式(Simple Factory Pattern):簡單工廠模式不屬於經典23種設計模式,但是因爲其簡單易用,在開發中經常用到。
在這裏插入圖片描述
結構型有7種設計模式:
6》代理模式( Proxy Pattern):爲其他對象提供一種代理以控制對這個對象的訪問。
在這裏插入圖片描述
7》裝飾者模式( Decorator Pattern ):動態的給一個對象添加一些額外的職責。
在這裏插入圖片描述
8》適配器模式( Adapter Pattern ):將一個類的接口轉換成客戶希望的另外一個接口,使得原本由於接口不兼容而不能一起工作的那些類可以一起工作。
在這裏插入圖片描述
9》橋接模式( Bridge Pattern):將抽象部分與實際部分分離,使它們都可以獨立的變化。
在這裏插入圖片描述
10》組合模式( Composite Pattern ):將對象組合成樹形結構以表示 “部分 --整體”的層次結構,使得用戶對單個對象和組合對象的使用具有一致性。
在這裏插入圖片描述
11》外觀模式 (Facade Pattern):爲子系統中的一組接口提供一個一致的界面, 此模式定義了一個高層接口,這個接口使得這一子系統更加容易使用。
在這裏插入圖片描述
12》享元模式( Flyweight Pattern ):以共享的方式高效的支持大量的細粒度的對象。
在這裏插入圖片描述

行爲型有11種設計模式:
13》模板方法模式( Template Method Pattern ):子類可以不改變一個算法的結構即可重定義該算法的某些特定步驟。
在這裏插入圖片描述
14》命令模式( Command Pattern ):將一個請求封裝爲一個對象,從而使你可用不同的請求對客戶端進行參數化、對請求排隊或記錄請求日誌、支持可撤銷的操作。
在這裏插入圖片描述
15》責任鏈模式( Chain of Responsibility Pattern ):很多對象由每一個對象對其下家的引用而連接起來形成一條鏈; 請求在這個鏈上傳遞, 直到鏈上的某一個對象決定處理此請求,這使得系統可在不影響客戶端的情況下動態地重新組織鏈和分配責任。
在這裏插入圖片描述
16》策略模式( Strategy Pattern ):準備一組算法,並將每一個算法封裝起來,使得它們可以換。
在這裏插入圖片描述
17》中介者模式( Mediator Pattern ):定義一箇中介對象來封裝系列對象之間的交互; 終結者使各個對象不需要顯示的相互調用 ,從而使其耦合性鬆散,而且可以獨立的改變他們之間的交互。
在這裏插入圖片描述
18》觀察者模式( Observer Pattern ):定義對象間的一種一對多的依賴關係,當一個對象的狀態發生改變時,所有依賴於它的對象都得到通知並被自動更新。
在這裏插入圖片描述
19》備忘錄模式 (Memento Pattern ):在不破壞封裝的前提下, 捕獲一個對象的內部狀態,並在該對象之外保存這個狀態。
在這裏插入圖片描述
20》訪問者模式( Visitor Pattern ):表示一個作用於某對象結構中的各元素的操作,它使你可以在不改變各元素的類的前提下定義作用於這些元素的新操作。
在這裏插入圖片描述
21》狀態模式( State Pattern):一個對象的行爲,依賴於它所處的當時狀態。
在這裏插入圖片描述
22》解釋器模式( Interpreter Pattern ):描述瞭如何爲簡單的語言定義一個語法,如何在該語言中表示一個句子,以及如何解釋這些句子。
在這裏插入圖片描述
23》迭代器模式( Iterator Pattern ):提供了一種方法順序來訪問一個聚合對象中的各個元素,而又不需要暴露該對象的內部表示。
在這裏插入圖片描述

四、設計模式的目的和核心

設計模式的最終目的是實現:高內聚,低耦合。

設計模式的核心就是繼承與多態,學習設計模式一定要理解繼承和多態。

五、設計模式源碼下載地址

1、CSDN下載地址
2、Github下載地址

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章