目錄
一、什么是設計模式
二、設計原則
三、設計模式的種類
代碼地址:patterns: 每日設計模式
一、什么是設計模式
軟件設計模式(Design Pattern)是一套被反復使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結,使用設計模式是為了可重用代碼、讓代碼更容易被他人理解并且保證代碼可靠性。
一句大白話可以總結:在一定環境下,用固定套路解決問題。
二、設計原則
對于面向對象軟件系統的設計而言,在支持可維護性的同時,提高系統的可復用性是一個至關重要的問題,如何同時提高一個軟件系統的可維護性和可復用性是面向對象設計需要解決的核心問題之一。在面向對象設計中,可維護性的復用是以設計原則為基礎的。每一個原則都蘊含一些面向對象設計的思想,可以從不同的角度提升一個軟件結構的設計水平。
面向對象設計原則為支持可維護性復用而誕生,這些原則蘊含在很多設計模式中,它們是從許多設計方案中總結出的指導性原則。面向對象設計原則也是我們用于評價一個設計模式的使用效果的重要指標之一。
原則的目的: 高內聚,低耦合
名稱 | 定義 |
單一職責原則 | 類的職責單一,對外只提供一種功能,而引起類變化的原因都應該只有一個。 |
(Single Responsibility Principle, SRP) | |
★★★★☆ | |
開閉原則 | 類的改動是通過增加代碼進行的,而不是修改源代碼。 |
(Open-Closed Principle, OCP) | |
★★★★★ | |
里氏代換原則 | 任何抽象類(interface接口)出現的地方都可以用他的實現類進行替換,實際就是虛擬機制,語言級別實現面向對象功能。 |
(Liskov Substitution Principle, LSP | |
★★★★★ | |
依賴倒轉原則 | 依賴于抽象(接口),不要依賴具體的實現(類),也就是針對接口編程。 |
(Dependence Inversion Principle, DIP) | |
★★★★★ | |
接口隔離原則 | 不應該強迫用戶的程序依賴他們不需要的接口方法。一個接口應該只提供一種對外功能,不應該把所有操作都封裝到一個接口中去。 |
(Interface Segregation Principle, ISP | |
★★☆☆☆ | |
合成復用原則 | 如果使用繼承,會導致父類的任何變換都可能影響到子類的行為。如果使用對象組合,就降低了這種依賴關系。對于繼承和組合,優先使用組合。 |
(Composite Reuse Principle, CRP) | |
★★★★☆ | |
迪米特法則 | 一個對象應當對其他對象盡可能少的了解,從而降低各個對象之間的耦合,提高系統的可維護性。例如在一個程序中,各個模塊之間相互調用時,通常會提供一個統一的接口來實現。這樣其他模塊不需要了解另外一個模塊的內部實現細節,這樣當一個模塊內部的實現發生改變時,不會影響其他模塊的使用。(黑盒原理) |
(Law of Demeter, LoD | |
★★★☆☆ |
三、設計模式的種類
- 創建型(Creational)模式:如何創建對象;
- 結構型(Structural )模式:如何實現類或對象的組合;
- 行為型(Behavioral)模式:類或對象怎樣交互以及怎樣分配職責。
有一個“簡單工廠模式”不屬于GoF 23種設計模式,但大部分的設計模式書籍都會對它進行專門的介紹。
模式名稱 | 模式名稱 | 作用 | |
創建型模式 Creational Pattern | 單例模式 | 是保證一個類僅有一個實例,并提供一個訪問它的全局訪問點。 | |
-6 | ★★★★☆ | ||
簡單工廠模式 | 通過專門定義一個類來負責創建其他類的實例,被創建的實例通常都具有共同的父類。 | ||
★★★☆☆ | |||
工廠方法模式 | 定義一個創建產品對象的工廠接口,將實際創建工作推遲到子類中。 | ||
★★★★★ | |||
抽象工廠模式 | 提供一個創建一系列相關或者相互依賴的接口,而無需指定它們具體的類。 | ||
★★★★★ | |||
原型模式 | 用原型實例指定創建對象的種類,并且通過拷貝這些原型創建新的對象。 | ||
★★★☆☆ | |||
建造者模式 | 將一個復雜的構建與其表示相分離,使得同樣的構建過程可以創建不同的表示。 | ||
★★☆☆☆ | |||
結構型模式 | 適配器模式 | 將一個類的接口轉換成客戶希望的另外一個接口。使得原本由于接口不兼容而不能一起工作的那些類可以一起工作。 | |
Structural Pattern | ★★★★☆ | ||
-7 | 橋接模式 | 將抽象部分與實際部分分離,使它們都可以獨立的變化。 | |
★★★☆☆ | |||
組合模式 | 將對象組合成樹形結構以表示“部分--整體”的層次結構。使得用戶對單個對象和組合對象的使用具有一致性。 | ||
★★☆☆☆ | |||
裝飾模式 | 動態的給一個對象添加一些額外的職責。就增加功能來說,此模式比生成子類更為靈活。 | ||
★★★☆☆ | |||
外觀模式 | 為子系統中的一組接口提供一個一致的界面,此模式定義了一個高層接口,這個接口使得這一子系統更加容易使用。 | ||
★★★★★ | |||
享元模式 | 以共享的方式高效的支持大量的細粒度的對象。 | ||
★☆☆☆☆ | |||
代理模式 | 為其他對象提供一種代理以控制對這個對象的訪問。 | ||
★★★★☆ | |||
行為型模式 | 職責鏈模式 | 在該模式里,很多對象由每一個對象對其下家的引用而連接起來形成一條鏈。請求在這個鏈上傳遞,直到鏈上的某一個對象決定處理此請求,這使得系統可以在不影響客戶端的情況下動態地重新組織鏈和分配責任。 | |
Behavioral Pattern | ★★☆☆☆ | ||
-11 | 命令模式 | 將一個請求封裝為一個對象,從而使你可用不同的請求對客戶端進行參數化;對請求排隊或記錄請求日志,以及支持可撤銷的操作。 | |
★★★★☆ | |||
解釋器模式 | 如何為簡單的語言定義一個語法,如何在該語言中表示一個句子,以及如何解釋這些句子。 | ||
★☆☆☆☆ | |||
迭代器模式 | 提供了一種方法順序來訪問一個聚合對象中的各個元素,而又不需要暴露該對象的內部表示。 | ||
★☆☆☆☆ | |||
中介者模式 | 定義一個中介對象來封裝系列對象之間的交互。終結者使各個對象不需要顯示的相互調用 ,從而使其耦合性松散,而且可以獨立的改變他們之間的交互。 | ||
★★☆☆☆ | |||
備忘錄模式 | 是在不破壞封裝的前提下,捕獲一個對象的內部狀態,并在該對象之外保存這個狀態。 | ||
★★☆☆☆ | |||
觀察者模式 | 定義對象間的一種一對多的依賴關系,當一個對象的狀態發生改變時,所有依賴于它的對象都得到通知并被自動更新。 | ||
★★★★★ | |||
狀態模式 | 對象的行為,依賴于它所處的狀態。 | ||
★★☆☆☆ | |||
策略模式 | 準備一組算法,并將每一個算法封裝起來,使得它們可以互換。 | ||
★★★★☆ | |||
模板方法模式 | 得子類可以不改變一個算法的結構即可重定義該算法的某些特定步驟。 | ||
★★★☆☆ | |||
訪問者模式 | 表示一個作用于某對象結構中的各元素的操作,它使你可以在不改變各元素的類的前提下定義作用于這些元素的新操作。 | ||
★☆☆☆☆ |