一、定義
設計模式是一套被反復使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結,使用設計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性、程式的重用性,
二、產生背景
肯特·貝克和沃德·坎寧安在1987年利用克里斯托佛·亞歷山大在建筑設計領域里的思想開發了設計模式并把此思想應用在Smalltalk中的圖形用戶介面的生成中,一年后Erich Gamma在他的蘇黎世大學博士畢業論文中開始嘗試把這種思想改寫為適用于軟體開發,與此同時James Coplien 在1989年至1991 年也在利用相同的思想致力于C++的開發,而后于1991年發表了他的著作Advanced C++ Idioms,就在這一年Erich Gamma 得到了博士學位,然后去了美國,在那與Richard Helm, Ralph Johnson ,John Vlissides合作出版了Design Patterns - Elements of Reusable Object-Oriented Software 一書,在此書中共收錄了23個設計模式,這四位作者在軟體開發領域里也以他們的匿名著稱Gang of Four(四人幫,簡稱GoF),并且是他們在此書中的協作導致了軟體設計模式的突破,有時這個匿名GoF也會用于指代前面提到的那本書,
三、學習的意義
設計模式的本質是面向物件設計原則的實際運用,是對類的封裝性、繼承性和多型性以及類的關聯關系和組合關系的充分理解,正確使用設計模式具有以下優點,
- 可以提高程式員的思維能力、編程能力和設計能力,
- 使程式設計更加標準化、代碼編制更加工程化,使軟體開發效率大大提高,從而縮短軟體的開發周期,
- 使設計的代碼可重用性高、可讀性強、可靠性高、靈活性好、可維護性強,
四、設計模式的分類
設計模式有兩種分類方法,即根據模式的目的來分和根據模式的作用的范圍來分,
1. 根據目的來分
根據模式是用來完成什么作業來劃分,這種方式可分為創建型模式、結構型模式和行為型模式 3 種,
- 創建型模式:用于描述“怎樣創建物件”,它的主要特點是“將物件的創建與使用分離”,GoF 中提供了單例、原型、工廠方法、抽象工廠、建造者等 5 種創建型模式,
- 結構型模式:用于描述如何將類或物件按某種布局組成更大的結構(物件和誰有關),GoF 中提供了代理、配接器、橋接、裝飾、外觀、享元、組合等 7 種結構型模式,
- 行為型模式:用于描述類或物件之間怎樣相互協作共同完成單個物件都無法單獨完成的任務(物件與物件在干嘛),以及怎樣分配職責,GoF 中提供了模板方法、策略、命令、職責鏈、狀態、觀察者、中介者、迭代器、訪問者、備忘錄、解釋器等 11 種行為型模式,
2. 根據作用范圍來分
根據模式是主要用于類上還是主要用于物件上來分,這種方式可分為類模式和物件模式兩種,
- 類模式:用于處理類與子類之間的關系,這些關系通過繼承來建立,是靜態的,在編譯時刻便確定下來了,GoF中的工廠方法、(類)配接器、模板方法、解釋器屬于該模式,
- 物件模式:用于處理物件之間的關系,這些關系可以通過組合或聚合來實作,在運行時刻是可以變化的,更具動態性,GoF 中除了以上 4 種,其他的都是物件模式,
具體分類如下圖所示

3. GoF的23種設計模式的功能
前面說明了 GoF 的 23 種設計模式的分類,現在對各個模式的功能進行介紹,
- 單例(Singleton)模式:某個類只能生成一個實體,該類提供了一個全域訪問點供外部獲取該實體,其拓展是有限多例模式,
- 原型(Prototype)模式:將一個物件作為原型,通過對其進行復制而克隆出多個和原型類似的新實體,
- 工廠方法(Factory Method)模式:定義一個用于創建產品的介面,由子類決定生產什么產品,
- 抽象工廠(AbstractFactory)模式:提供一個創建產品族的介面,其每個子類可以生產一系列相關的產品,
- 建造者(Builder)模式:將一個復雜物件分解成多個相對簡單的部分,然后根據不同需要分別創建它們,最后構建成該復雜物件,
- 代理(Proxy)模式:為某物件提供一種代理以控制對該物件的訪問,即客戶端通過代理間接地訪問該物件,從而限制、增強或修改該物件的一些特性,
- 配接器(Adapter)模式:將一個類的介面轉換成客戶希望的另外一個介面,使得原本由于介面不兼容而不能一起作業的那些類能一起作業,
- 橋接(Bridge)模式:將抽象與實作分離,使它們可以獨立變化,它是用組合關系代替繼承關系來實作,從而降低了抽象和實作這兩個可變維度的耦合度,
- 裝飾(Decorator)模式:動態的給物件增加一些職責,即增加其額外的功能,
- 外觀(Facade)模式:為多個復雜的子系統提供一個一致的介面,使這些子系統更加容易被訪問,
- 享元(Flyweight)模式:運用共享技術來有效地支持大量細粒度物件的復用,
- 組合(Composite)模式:將物件組合成樹狀層次結構,使用戶對單個物件和組合物件具有一致的訪問性,
- 模板方法(TemplateMethod)模式:定義一個操作中的演算法骨架,而將演算法的一些步驟延遲到子類中,使得子類可以不改變該演算法結構的情況下重定義該演算法的某些特定步驟,
- 策略(Strategy)模式:定義了一系列演算法,并將每個演算法封裝起來,使它們可以相互替換,且演算法的改變不會影響使用演算法的客戶,
- 命令(Command)模式:將一個請求封裝為一個物件,使發出請求的責任和執行請求的責任分割開,
- 職責鏈(Chain of Responsibility)模式:把請求從鏈中的一個物件傳到下一個物件,直到請求被回應為止,通過這種方式去除物件之間的耦合,
- 狀態(State)模式:允許一個物件在其內部狀態發生改變時改變其行為能力,
- 觀察者(Observer)模式:多個物件間存在一對多關系,當一個物件發生改變時,把這種改變通知給其他多個物件,從而影響其他物件的行為,
- 中介者(Mediator)模式:定義一個中介物件來簡化原有物件之間的互動關系,降低系統中物件間的耦合度,使原有物件之間不必相互了解,
- 迭代器(Iterator)模式:提供一種方法來順序訪問聚合物件中的一系列資料,而不暴露聚合物件的內部表示,
- 訪問者(Visitor)模式:在不改變集合元素的前提下,為一個集合中的每個元素提供多種訪問方式,即每個元素有多個訪問者物件訪問,
- 備忘錄(Memento)模式:在不破壞封裝性的前提下,獲取并保存一個物件的內部狀態,以便以后恢復它,
- 解釋器(Interpreter)模式:提供如何定義語言的文法,以及對語言句子的解釋方法,即解釋器,
必須指出,這 23 種設計模式不是孤立存在的,很多模式之間存在一定的關聯關系,在大的系統開發中常常同時使用多種設計模式,希望讀者認真學好它們,在接下來的文章中會對各種設計模式進行詳細的解釋,
五、設計模式的八大原則
1.開閉原則(目標,總的指導思想)
對拓展開放,對修改關閉
增加新功能,不改變原有代碼
2.類的職責單一(一個類的定義)
一個類有且只有一個改變它的原因
適用于基礎類,不適用于基于基礎類構建的聚合類
3.依賴倒置(依賴抽象)
客戶端代碼(呼叫的類)盡量依賴(使用)抽象的組件,(即依賴父類而不是依賴子類)
抽象是穩定的,實作是多變的
4.組合復用 原則(復用的最佳實踐)
如果僅僅為了代碼復用優先選擇組合復用,而不是繼承復用
組合的耦合性相對繼承低
5.里式替換(繼承后的重寫,指導繼承的設計)
父類出現的地方可以被子類替換(宣告父存放子類物件),在替換后依然保持原有功能
子類要擁有父類的所有功能
子類在重寫父類方法時,盡量選擇擴展重寫,防止改變了功能
6.介面隔離(功能拆分)
盡量定義小而精的介面,少定義大而全的介面,本質與單一職責相同
小介面之間功能隔離,實作類需要多個功能時可以選擇多實作,
7.面向介面編程而非面向實作(切換、并行開發)
客戶端通過一系列抽象操作實體,而無需關注具體型別
便于靈活切換一系列功能
實作軟體的并行開發
8.迪米特法則(類與類互動的原則)
不要和陌生人說話
類與類互動時,在滿足功能要求的基礎上,傳遞的資料量越少越好,因為這樣可以降低耦合度
六、設計的主要思想
分而治之 ---- 將一個大的需求分解成許多類,每個類處理一個獨立的模塊
拆分的好處:獨立模塊便于分工,每個模塊便于復用,可拓展性強
封裝變化 ---- 變化的地方(可能變化的功能)獨立封裝,避免影響其他模塊
高內聚 ---- 類中各個方法都在完成一項任務(單一職責的類)
復雜的實作封裝在內部,對外提供簡單的呼叫
低耦合 ---- 類與類的關聯性依賴要低(每個類獨立)
當一個模塊的改變,盡量少影響其他模塊
最高的內聚莫過于類中僅包含一個方法,這將會導致高內聚高耦合,
最低的耦合莫過于類中包含所有方法,這將會導致低耦合低內聚
轉載請註明出處,本文鏈接:https://www.uj5u.com/ruanti/4546.html
標籤:設計模式
上一篇:設計模式(5) 原型模式
下一篇:設計模式(6) 配接器模式
