天天看點

程式員内功-設計模式篇

作者:Hu先生Linux背景開發

一. 什麼是設計模式

  糾結了好久,今天終于下定決心開始寫設計模式系列,因為這個系列章節确實不好寫,在這之前,也看了好多關于設計模式的部落格、視訊、書籍等,最後結合自己的了解,親自動手實操代碼,完成該章節。

  我也和我同行的朋友交流了一下關于設計模式,對設計模式的了解,可以分為這麼幾個層次:

  ①:根本不知道什麼是設計模式。

  ②:聽說過幾種設計模式,了解不深。

  ③:能寫出并了解幾種設計模式,但不知道在項目中該怎麼用。

  毋庸置疑,能否靈活的運用好設計模式,是一個名開發工程師邁向架構師的必經之路,上面說的這麼玄乎,那麼到底什麼是涉及模式呢?這裡先借助金庸的武俠小說來類比一下。

  作為金庸迷的我,金庸老師的“飛雪連天射白鹿,笑書神俠倚碧鴛”14部小說每一部看了都不低于3遍以上,對裡面個各種武功也是了如指掌,像效果比較炫麗,威力比較大的有:“喬幫主降龍十八掌、段譽的六脈神劍、楊過的黯然銷魂掌、任我行的吸星大法等等”,這些都是外家功夫,種類很多,一個人可能會多種,這就好比.Net的中MVC、EF、SignalR等等;當然也有内功心法,典型的有:”少林和尚的易筋經、張無忌的九陽神功”,這兩種功夫本身并沒有太大的殺傷力,但會了這種功夫,更容易融會貫通外家功夫,使外家功夫發揮出更大效果,拿到我們開發領域,“設計模式”就是内功心法,沒有語言之分,它是一種模式,一種思想指導着我們開發。

那麼怎麼才能算精通設計模式呢?

  看過《倚天屠龍記》的朋友可能會記得裡面有這麼一個場景:趙敏冒充明教挑戰張三豐的時候,張無忌辦成小道童出來救場,在對陣三個家奴的的時候,張三豐教了張無忌一套太極拳法,裡面有這麼一段對話:

程式員内功-設計模式篇
程式員内功-設計模式篇

  張三豐示範完後,問張無忌:“無忌,你記住了多少”,張無忌回答說:“無忌不才,隻有一小部分沒有記住”;過了一會,張三豐又問道:“現在能記住多少”,無忌說:“太師傅,我已經全部忘記了”,這時,張三豐說:“無忌你可以上了”,結果顯然而知,對手被打的那叫一個慘啊。

是以:設計模式的最高境界是,忘記設計模式,将23種的設計模式自然而然的融入開發中,哈哈,當然這個有點難,沒有個幾年以上的功力,很難達到這個層次。

二. 設計模式的内容

 設計模式是一種套路,是把 “别人成功的例子” 拿過來靈活運用,我們的優秀的前輩總結出來7個設計原則和23種設計模式。

1. 先說設計原則

設計原則:

    1. 單一職責原則

    2. 裡氏替換原則

    3. 依賴倒置原則

    4. 接口隔離原則

    5. 迪米特原則(最小知道原則)

    6. 開閉原則

    7. 組合聚合原則  

  這 7 種設計原則是【軟體設計模式】必須盡量遵循的原則,各種原則要求的側重點不同。

 (1). 開閉原則是總綱,它告訴我們要對擴充開放,對修改關閉;

 (2). 裡氏替換原則告訴我們不要破壞繼承體系;

 (3). 依賴倒置原則告訴我們要面向接口程式設計;

 (4). 單一職責原則告訴我們實作類要職責單一;

 (5). 接口隔離原則告訴我們在設計接口的時候要精簡單一;

 (6). 迪米特法則告訴我們要降低耦合度;

 (7). 組合聚合原則告訴我們要優先使用組合或者聚合關系複用,少用繼承關系複用。

C++背景開發架構師免費學習位址:C/C++Linux鏈嶅姟鍣ㄥ紑鍙�/鍚庡彴鏋舵瀯甯堛€愰浂澹版暀鑲層€�-瀛︿範瑙嗛鏁欑▼-鑵捐璇懼爞

【文章福利】另外還整理一些C++背景開發架構師 相關學習資料,面試題,教學視訊,以及學習路線圖,免費分享有需要的可以自行點選 「連結」 群檔案共享

程式員内功-設計模式篇

2. 再談設計模式

(1). 根據目的來劃分

設計模式:

  1. 建立型模式 :工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。   2. 結構型模式:擴充卡模式、裝飾器模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。

  3. 行為型模式:政策模式、模闆方法模式、觀察者模式、疊代器模式、責任鍊模式、指令模式、備忘錄模式、狀态模式、通路者模式、中介者模式、解釋器模式。

A. 建立型模式

 主要關注點是“怎樣建立對象?”,它的主要特點是“将對象的建立與使用分離”。這樣可以降低系統的耦合度,使用者不需要關注對象的建立細節,對象的建立由相關的工廠來完成。就像我們去商場購買商品時,不需要知道商品是怎麼生産出來一樣,因為它們由專門的廠商生産。

B. 結構型模式

結構型模式描述如何将類或對象按某種布局組成更大的結構。它分為類結構型模式和對象結構型模式,前者采用繼承機制來組織接口和類,後者釆用組合或聚合來組合對象。由于組合關系或聚合關系比繼承關系耦合度低,滿足“合成複用原則”,是以對象結構型模式比類結構型模式具有更大的靈活性。

C.行為型模式

 用于描述程式在運作時複雜的流程控制,即描述多個類或對象之間怎樣互相協作共同完成單個對象都無法單獨完成的任務,它涉及算法與對象間職責的配置設定。

 行為型模式分為類行為模式和對象行為模式,前者采用繼承機制來在類間分派行為,後者采用組合或聚合在對象間配置設定行為。由于組合關系或聚合關系比繼承關系耦合度低,滿足“合成複用原則”,是以對象行為模式比類行為模式具有更大的靈活性。

(2). 根據作用範圍來劃分

A. 類模式

 用于處理類與子類之間的關系,這些關系通過繼承來建立,是靜态的,在編譯時刻便确定下來了。GoF中的工廠方法、(類)擴充卡、模闆方法、解釋器屬于該模式。

B. 對象模式

 用于處理對象之間的關系,這些關系可以通過組合或聚合來實作,在運作時刻是可以變化的,更具動态性。GoF 中除了以上 4 種,其他的都是對象模式。

(3). 用一張表格來彙總

程式員内功-設計模式篇

3. 一句話總結23種設計模式

 (1). 單例(Singleton)模式:某個類隻能生成一個執行個體,該類提供了一個全局通路點供外部擷取該執行個體(不能new建立對象),其拓展是有限多例模式。

 (2). 原型(Prototype)模式:将一個對象作為原型,通過對其進行複制而克隆出多個和原對象相同或類似的新執行個體。

 (3). 工廠方法(Factory Method)模式:定義一個用于建立産品的接口,由子類決定生産什麼産品。

 (4). 抽象工廠(AbstractFactory)模式:提供一個建立産品族的接口,其每個子類可以生産一系列相關的産品。

 (5). 建造者(Builder)模式:将一個複雜對象分解成多個相對簡單的部分,然後根據不同需要分别建立它們,最後建構成該複雜對象。

 (6). 代理(Proxy)模式:為某對象提供一種代理以控制對該對象的通路。即用戶端通過代理間接地通路該對象,進而限制、增強或修改該對象的一些特性。

 (7). 擴充卡(Adapter)模式:将一個類的接口轉換成客戶希望的另外一個接口,使得原本由于接口不相容而不能一起工作的那些類能一起工作。

(8). 橋接(Bridge)模式:将抽象與實作分離,使它們可以獨立變化。它是用組合關系代替繼承關系來實作,進而降低了抽象和實作這兩個可變次元的耦合度。

 (9). 裝飾(Decorator)模式:動态的給對象增加一些職責,即增加其額外的功能。

 (10). 外觀(Facade)模式:為多個複雜的子系統提供一個一緻的接口,使這些子系統更加容易被通路。

(11). 享元(Flyweight)模式:運用共享技術來有效地支援大量細粒度對象的複用。

 (12). 組合(Composite)模式:将對象組合成樹狀層次結構,使使用者對單個對象群組合對象具有一緻的通路性。

 (13). 模闆方法(TemplateMethod)模式:定義一個操作中的算法骨架,而将算法的一些步驟延遲到子類中,使得子類可以不改變該算法結構的情況下重定義該算法的某些特定步驟。

 (14). 政策(Strategy)模式:定義了一系列算法,并将每個算法封裝起來,使它們可以互相替換,且算法的改變不會影響使用算法的客戶。

(15). 指令(Command)模式:将一個請求封裝為一個對象,使送出請求的責任和執行請求的責任分割開。

 (16). 責任鍊(Chain of Responsibility)模式:把請求從鍊中的一個對象傳到下一個對象,直到請求被響應為止。通過這種方式去除對象之間的耦合。

(17). 狀态(State)模式:允許一個對象在其内部狀态發生改變時改變其行為能力。

 (18). 觀察者(Observer)模式:多個對象間存在一對多關系,當一個對象發生改變時,把這種改變通知給其他多個對象,進而影響其他對象的行為。

 (19). 中介者(Mediator)模式:定義一個中介對象來簡化原有對象之間的互動關系,降低系統中對象間的耦合度,使原有對象之間不必互相了解(多對多)。

 (20). 疊代器(Iterator)模式:提供一種方法來順序通路聚合對象中的一系列資料,而不暴露聚合對象的内部表示。

(21). 通路者(Visitor)模式:在不改變集合元素的前提下,為一個集合中的每個元素提供多種通路方式,即每個元素有多個通路者對象通路。

(22). 備忘錄(Memento)模式:在不破壞封裝性的前提下,擷取并儲存一個對象的内部狀态,以便以後恢複它。

(23). 解釋器(Interpreter)模式:提供如何定義語言的文法,以及對語言句子的解釋方法,即解釋器。

原文連結:程式員内功--設計模式篇 - Yaopengfei - 部落格園

繼續閱讀