C++ 設計模式

C++ 設計模式

置頂 2018年02月09日 09:26:25  閱讀數:18880 標籤: C++C++設計模式設計模式GoFGoF設計模式 更多

個人分類: C++ 設計模式

所屬專欄: C++ 設計模式

版權聲明:本文爲博主原創文章,未經博主允許不得轉載。 https://blog.csdn.net/u011012932/article/details/66974516

設計模式

設計模式(Design Pattern)代表了最佳的實踐,在面向對象的編程中被很多老鳥們反覆使用。使用設計模式有很多好處:

  • 可重用代碼
  • 保證代碼可靠性
  • 使代碼更易被他人理解
  • ……

毫無疑問,設計模式於己、於人、於系統都是多贏的。《設計模式》之於程序員,就好比《聖經》之於耶穌信徒一樣,意義可想而知!

版權聲明:一去、二三裏,未經博主允許不得轉載。

什麼是 GoF

談及設計模式,必然離不開 GoF:

GoF:Gang of Four,也稱爲“四人組”,即:EErich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides 四人。

1994 年,這幾位大牛合著出版了一本名爲《Design Patterns: Elements of Reusable Object-Oriented Software》(即:《設計模式》)的書。該書首次提到了軟件開發中設計模式的概念,將設計模式提升到理論高度,並將之規範化。書中提及了 23 種基本設計模式,時至今日,在可複用面向對象軟件的發展過程中,新的設計模式仍然不斷出現。

這裏寫圖片描述

這就是傳說中的“風塵四俠”,比起國外的其他技術大咖(不修邊幅),看起來要好很多~O(∩_∩)O~。

設計模式的類型

根據《設計模式》參考書,共有 23 種設計模式,這些模式可以分爲三類:

類型 描述
創建型模式(Creational Patterns) 用於構建對象,以便它們可以從實現系統中分離出來。
結構型模式(Structural Patterns) 用於在許多不同的對象之間形成大型對象結構。
行爲型模式(Behavioral Patterns) 用於管理對象之間的算法、關係和職責。

創建型模式

  • 單例模式(Singleton Pattern) 
    保證一個類僅有一個實例,並提供一個訪問它的全局訪問點。

  • 抽象工廠模式 (Abstract Factory Pattern) 
    提供一個創建一系列相關或相互依賴對象的接口,而無需指定它們具體的類。

  • 建造者模式(Builder Pattern) 
    將一個複雜對象的構建與它的表示分離,使得同樣的構建過程可以創建不同的表示。

  • 工廠方法模式 (Factory Method Pattern) 
    定義一個用於創建對象的接口,讓子類決定將哪一個類實例化。Factory Method 使一個類的實例化延遲到其子類。

  • 原型模式(Prototype Pattern) 
    用原型實例指定創建對象的種類,並且通過拷貝這個原型來創建新的對象。

結構型模式

  • 適配器模式(Adapter Pattern) 
    將一個類的接口轉換成客戶希望的另外一個接口。Adapter 模式使得原本由於接口不兼容而不能一起工作的那些類可以一起工作。

  • 橋接模式(Bridge Pattern) 
    將抽象部分與它的實現部分分離,使它們都可以獨立地變化。

  • 裝飾者模式(Decorator Pattern) 
    動態地給一個對象添加一些額外的職責。就擴展功能而言,它比生成子類方式更爲靈活。

  • 組合模式(Composite Pattern) 
    將對象組合成樹形結構以表示“部分-整體”的層次結構。它使得客戶對單個對象和複合對象的使用具有一致性。

  • 外觀模式(Facade Pattern) 
    爲子系統中的一組接口提供一個一致的界面,Facade 模式定義了一個高層接口,這個接口使得這一子系統更加容易使用。

  • 享元模式(Flyweight Pattern) 
    運用共享技術有效地支持大量細粒度的對象。

  • 代理模式(Proxy Pattern) 
    爲其他對象提供一個代理以控制對這個對象的訪問。

行爲型模式

  • 模版方法模式 (Template Method Pattern) 
    定義一個操作中的算法的骨架,而將一些步驟延遲到子類中。Template Method 使得子類可以不改變一個算法的結構即可重定義該算法的某些特定步驟。

  • 命令模式(Command Pattern) 
    將一個請求封裝爲一個對象,從而使你可用不同的請求對客戶進行參數化;對請求排隊或記錄請求日誌,以及支持可取消的操作。

  • 迭代器模式(Iterator Pattern) 
    提供一種方法順序訪問一個聚合對象中各個元素,而又不需暴露該對象的內部表示。

  • 觀察者模式(Observer Pattern) 
    定義對象間的一種一對多的依賴關係,以便當一個對象的狀態發生改變時,所有依賴於它的對象都得到通知並自動刷新。

  • 中介者模式(Mediator Pattern) 
    用一箇中介對象來封裝一系列的對象交互。中介者使各對象不需要顯式地相互引用,從而使其耦合鬆散,而且可以獨立地改變它們之間的交互。

  • 備忘錄模式 (Memento Pattern) 
    在不破壞封裝性的前提下,捕獲一個對象的內部狀態,並在該對象之外保存這個狀態。這樣以後就可將該對象恢復到保存的狀態。

  • 解釋器模式(Interpreter Pattern) 
    給定一個語言,定義它的文法的一種表示,並定義一個解釋器,該解釋器使用該表示來解釋語言中的句子。

  • 狀態模式(State Pattern) 
    允許一個對象在其內部狀態改變時改變它的行爲。對象看起來似乎修改了它所屬的類。

  • 策略模式(Strategy Pattern) 
    定義一系列的算法,把它們一個個封裝起來,並且使它們可相互替換。本模式使得算法的變化可獨立於使用它的客戶端。

  • 職責鏈模式 (Chain of Responsibility Pattern) 
    爲解除請求的發送者和接收者之間耦合,而使多個對象都有機會處理這個請求。將這些對象連成一條鏈,並沿着這條鏈傳遞該請求,直到有一個對象處理它。

  • 訪問者模式 (Visitor Pattern) 
    表示一個作用於某對象結構中的各元素的操作。它使你可以在不改變各元素的類的前提下定義作用於這些元素的新操作。

N 問設計模式

  • GoF 中提出的設計模式,至今仍被人津津樂道,你瞭解多少呢?

    • 沒聽過
    • 聽說過,不知道具體能幹嘛
    • 瞭解,會用其中的兩三種
    • 熟悉,能根據實際情況快速設計
    • 精通,遊刃有餘

    第一種:“雖然不懂你們在說什麼,貌似很厲害的樣子”。大牛纔會用到的東西,高端而又神祕! 
    最後一種:“已上天,正和太陽肩並肩”。心中未曾想用設計模式,寫出的代碼卻處處都是。 
    倘若你和我一樣,屬於其他情況。。。那麼,就認真學習吧!

  • 設計模式能帶給你什麼?

    Design pattern

    從“猿猴 -> 程序猿 ”的鉅變,怎麼樣,是不是很炫酷?

  • 有些人說設計模式沒用,真是這樣嗎?

    引用一句哲學名言:存在即合理。當然,若要扯非 OO 語言,也許真沒什麼用!但可以肯定的是,非 OO 語言完全可以借鑑 OO 的思想,設計模式也不例外!

  • 設計模式有多重要?

    要做一位大神或所謂的高手,基本之一就是要懂得若干設計模式。設計模式是軟件工程的基石脈絡,如同大廈的結構一樣,你說有多重要?

  • 怎麼學習設計模式?

    設計模式不是基於理論發明的,而是先有問題場景,再基於需求和情景不斷演化設計方案,最後把一些方案標準化成“模式”。

    所以,通過實際案例學習是最好的!在討論每一個設計模式時,要儘量用生活中的真實問題來理解和分析。然後嘗試一步步地闡述設計,並以一個能匹配某些模式的設計收尾。

    通過先分析問題,然後闡述解決方案,最後得到一個設計模式,這樣就不用死記那些圖形和定義了!

  • 如何選擇設計模式?

    設計模式是針對某種情景下某種問題的某種解決方案,也就是說,每個模式都有自己的使用場景、使用方法和使用後果。正所謂物有兩極,各模式也存在相應的優缺點,得其優,而避其劣,終得之!

  • 爲什麼要寫設計模式?

    雖然設計模式被很多人唸叨並不斷書寫,但筆者還是決定追隨前人的腳步。我很喜歡一句話:“你會了不代表你真的會,要是你能讓別人也會,你纔是正的會了”!

源碼地址

要真正領悟設計模式的精髓,需要有大量實踐經驗的積累,這往往是一個漫長的過程。

博客中涉及的所有設計模式都基於實際案例,經過反覆打磨。。。爲了使其更加生動、形象,每個模式都有相應的故事化講解。

相關源碼均在筆者的 GitHub 中可以找到,全部經過驗證。

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