主頁 > 軟體設計 > 設計模式概述

設計模式概述

2020-09-11 05:59:16 軟體設計

一、定義

  設計模式是一套被反復使用、多數人知曉的、經過分類編目的、代碼設計經驗的總結,使用設計模式是為了可重用代碼、讓代碼更容易被他人理解、保證代碼可靠性、程式的重用性,

 

二、產生背景

  肯特·貝克和沃德·坎寧安在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 種,

    1. 創建型模式:用于描述“怎樣創建物件”,它的主要特點是“將物件的創建與使用分離”,GoF 中提供了單例、原型、工廠方法、抽象工廠、建造者等 5 種創建型模式,
    2. 結構型模式:用于描述如何將類或物件按某種布局組成更大的結構(物件和誰有關),GoF 中提供了代理、配接器、橋接、裝飾、外觀、享元、組合等 7 種結構型模式,
    3. 行為型模式:用于描述類或物件之間怎樣相互協作共同完成單個物件都無法單獨完成的任務(物件與物件在干嘛),以及怎樣分配職責,GoF 中提供了模板方法、策略、命令、職責鏈、狀態、觀察者、中介者、迭代器、訪問者、備忘錄、解釋器等 11 種行為型模式,

2. 根據作用范圍來分

根據模式是主要用于類上還是主要用于物件上來分,這種方式可分為類模式和物件模式兩種,

    1. 類模式:用于處理類與子類之間的關系,這些關系通過繼承來建立,是靜態的,在編譯時刻便確定下來了,GoF中的工廠方法、(類)配接器、模板方法、解釋器屬于該模式,
    2. 物件模式:用于處理物件之間的關系,這些關系可以通過組合或聚合來實作,在運行時刻是可以變化的,更具動態性,GoF 中除了以上 4 種,其他的都是物件模式,

    具體分類如下圖所示

            

 

 

   

3. GoF的23種設計模式的功能

前面說明了 GoF 的 23 種設計模式的分類,現在對各個模式的功能進行介紹,

    1. 單例(Singleton)模式:某個類只能生成一個實體,該類提供了一個全域訪問點供外部獲取該實體,其拓展是有限多例模式,
    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)模式:提供如何定義語言的文法,以及對語言句子的解釋方法,即解釋器,


必須指出,這 23 種設計模式不是孤立存在的,很多模式之間存在一定的關聯關系,在大的系統開發中常常同時使用多種設計模式,希望讀者認真學好它們,在接下來的文章中會對各種設計模式進行詳細的解釋,

 

五、設計模式的八大原則

  1.開閉原則(目標,總的指導思想)

    對拓展開放,對修改關閉

    增加新功能,不改變原有代碼

   2.類的職責單一(一個類的定義)

  一個類有且只有一個改變它的原因

  適用于基礎類,不適用于基于基礎類構建的聚合類

   3.依賴倒置(依賴抽象)

  客戶端代碼(呼叫的類)盡量依賴(使用)抽象的組件,(即依賴父類而不是依賴子類)

  抽象是穩定的,實作是多變的

   4.組合復用 原則(復用的最佳實踐)

  如果僅僅為了代碼復用優先選擇組合復用,而不是繼承復用

  組合的耦合性相對繼承低

   5.里式替換(繼承后的重寫,指導繼承的設計)

  父類出現的地方可以被子類替換(宣告父存放子類物件),在替換后依然保持原有功能

  子類要擁有父類的所有功能

  子類在重寫父類方法時,盡量選擇擴展重寫,防止改變了功能

   6.介面隔離(功能拆分)

  盡量定義小而精的介面,少定義大而全的介面,本質與單一職責相同

  小介面之間功能隔離,實作類需要多個功能時可以選擇多實作,

   7.面向介面編程而非面向實作(切換、并行開發)

  客戶端通過一系列抽象操作實體,而無需關注具體型別

  便于靈活切換一系列功能

  實作軟體的并行開發

   8.迪米特法則(類與類互動的原則)

  不要和陌生人說話

    類與類互動時,在滿足功能要求的基礎上,傳遞的資料量越少越好,因為這樣可以降低耦合度

 

六、設計的主要思想

分而治之 ----  將一個大的需求分解成許多類,每個類處理一個獨立的模塊

   拆分的好處:獨立模塊便于分工,每個模塊便于復用,可拓展性強

 

封裝變化 ----  變化的地方(可能變化的功能)獨立封裝,避免影響其他模塊

 

高內聚  ----  類中各個方法都在完成一項任務(單一職責的類)

  復雜的實作封裝在內部,對外提供簡單的呼叫

 

低耦合  ----  類與類的關聯性依賴要低(每個類獨立)

  當一個模塊的改變,盡量少影響其他模塊

 

 

最高的內聚莫過于類中僅包含一個方法,這將會導致高內聚高耦合,

最低的耦合莫過于類中包含所有方法,這將會導致低耦合低內聚

 

 

 

轉載請註明出處,本文鏈接:https://www.uj5u.com/ruanti/4546.html

標籤:設計模式

上一篇:設計模式(5) 原型模式

下一篇:設計模式(6) 配接器模式

標籤雲
其他(157675) Python(38076) JavaScript(25376) Java(17977) C(15215) 區塊鏈(8255) C#(7972) AI(7469) 爪哇(7425) MySQL(7132) html(6777) 基礎類(6313) sql(6102) 熊猫(6058) PHP(5869) 数组(5741) R(5409) Linux(5327) 反应(5209) 腳本語言(PerlPython)(5129) 非技術區(4971) Android(4554) 数据框(4311) css(4259) 节点.js(4032) C語言(3288) json(3245) 列表(3129) 扑(3119) C++語言(3117) 安卓(2998) 打字稿(2995) VBA(2789) Java相關(2746) 疑難問題(2699) 细绳(2522) 單片機工控(2479) iOS(2429) ASP.NET(2402) MongoDB(2323) 麻木的(2285) 正则表达式(2254) 字典(2211) 循环(2198) 迅速(2185) 擅长(2169) 镖(2155) 功能(1967) .NET技术(1958) Web開發(1951) python-3.x(1918) HtmlCss(1915) 弹簧靴(1913) C++(1909) xml(1889) PostgreSQL(1872) .NETCore(1853) 谷歌表格(1846) Unity3D(1843) for循环(1842)

熱門瀏覽
  • 面試突擊第一季,第二季,第三季

    第一季必考 https://www.bilibili.com/video/BV1FE411y79Y?from=search&seid=15921726601957489746 第二季分布式 https://www.bilibili.com/video/BV13f4y127ee/?spm_id_fro ......

    uj5u.com 2020-09-10 05:35:24 more
  • 第三單元作業總結

    1.前言 這應該是本學期最后一次寫作業總結了吧。總體來說,對作業的節奏也差不多掌握了,作業做起來的效率也更高了。雖然和之前的作業一樣,作業中都要用到新的知識,但是相比之前,更加懂得了如何利用工具以及資料。雖然之間卡過殼,但總體而言,這幾次作業還算完成的比較好。 2.作業程序總結 相比前兩個單元,此單 ......

    uj5u.com 2020-09-10 05:35:41 more
  • 北航OO(2020)第四單元博客作業暨課程總結博客

    北航OO(2020)第四單元博客作業暨課程總結博客 本單元作業的架構設計 在本單元中,由于UML圖具有比較清晰的樹形結構,因此我對其中需要進行查詢操作的元素進行了包裝,在樹的父節點中存盤所有孩子的參考。考慮到性能問題,我采用了快取機制,一次查詢后盡可能快取已經遍歷過的資訊,以減少遍歷次數。 本單元我 ......

    uj5u.com 2020-09-10 05:35:48 more
  • BUAA_OO_第四單元

    一、UML決議器設計 ? 先看下題目:第四單元實作一個基于JDK 8帶有效性檢查的UML(Unified Modeling Language)類圖,順序圖,狀態圖分析器 MyUmlInteraction,實際上我們要建立一個有向圖模型,UML中的物件(元素)可能與同級元素連接,也可與低級元素相連形成 ......

    uj5u.com 2020-09-10 05:35:54 more
  • 6.1邏輯運算子

    邏輯運算子 1. && 短路與 運算式1 && 運算式2 01.運算式1為true并且運算式2也為true 整體回傳為true 02.運算式1為false,將不會執行運算式2 整體回傳為false 03.只要有一個運算式為false 整體回傳為false 2. || 短路或 運算式1 || 運算式2 ......

    uj5u.com 2020-09-10 05:35:56 more
  • BUAAOO 第四單元 & 課程總結

    1. 第四單元:StarUml檔案決議 本單元采用了圖模型決議UML。 UML檔案可以抽象為圖、子圖、邊的邏輯結構。 在實作中,圖的節點包括類、介面、屬性,子圖包括狀態圖、順序圖等。 采用了三次遍歷UML元素的方法建圖,第一遍遍歷建點,第二、三次遍歷設定屬性、連邊,實作圖物件的初始化。這里借鑒了一些 ......

    uj5u.com 2020-09-10 05:36:06 more
  • 談談我對C# 多型的理解

    面向物件三要素:封裝、繼承、多型。 封裝和繼承,這兩個比較好理解,但要理解多型的話,可就稍微有點難度了。今天,我們就來講講多型的理解。 我們應該經常會看到面試題目:請談談對多型的理解。 其實呢,多型非常簡單,就一句話:呼叫同一種方法產生了不同的結果。 具體實作方式有三種。 一、多載 多載很簡單。 p ......

    uj5u.com 2020-09-10 05:36:09 more
  • Python 資料驅動工具:DDT

    背景 python 的unittest 沒有自帶資料驅動功能。 所以如果使用unittest,同時又想使用資料驅動,那么就可以使用DDT來完成。 DDT是 “Data-Driven Tests”的縮寫。 資料:http://ddt.readthedocs.io/en/latest/ 使用方法 dd. ......

    uj5u.com 2020-09-10 05:36:13 more
  • Python里面的xlrd模塊詳解

    那我就一下面積個問題對xlrd模塊進行學習一下: 1.什么是xlrd模塊? 2.為什么使用xlrd模塊? 3.怎樣使用xlrd模塊? 1.什么是xlrd模塊? ?python操作excel主要用到xlrd和xlwt這兩個庫,即xlrd是讀excel,xlwt是寫excel的庫。 今天就先來說一下xl ......

    uj5u.com 2020-09-10 05:36:28 more
  • 當我們創建HashMap時,底層到底做了什么?

    jdk1.7中的底層實作程序(底層基于陣列+鏈表) 在我們new HashMap()時,底層創建了默認長度為16的一維陣列Entry[ ] table。當我們呼叫map.put(key1,value1)方法向HashMap里添加資料的時候: 首先,呼叫key1所在類的hashCode()計算key1 ......

    uj5u.com 2020-09-10 05:36:38 more
最新发布
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式,它可以用來減少類之間的直接依賴關系,
    * 將物件之間的通信封裝到一個中介者物件中,從而使得各個物件之間的關系更加松散。
    * 在中介者模式中,物件之間不再直接相互互動,而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:20:47 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點,專案投資大概1億,包括了礦山的各方面的內容,顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃,有很多煤礦行業專家的加持,他們的描述是非常完美,但是去年底應該上線的平臺,現在還沒有看到影子。他們確實有很多場景需求,但是被... ......

    uj5u.com 2023-04-20 08:20:25 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序,開始編碼、測驗、除錯之前進行需求分析和架構設計,才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:20:17 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師,不僅僅要緊跟行業技術趨勢,還要結合研發團隊現狀及痛點,探索新的交付方案。在日常中,你是否遇到如下問題 “ 業務需求排期長研發是瓶頸;非研發角色感受不到研發技改提效的變化;引入ISV 團隊又擔心質量和安全,培訓周期長“等等,基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:20:10 more
  • 【中介者設計模式詳解】C/Java/JS/Go/Python/TS不同語言實作

    * 中介者模式是一種行為型設計模式,它可以用來減少類之間的直接依賴關系,
    * 將物件之間的通信封裝到一個中介者物件中,從而使得各個物件之間的關系更加松散。
    * 在中介者模式中,物件之間不再直接相互互動,而是通過中介者來中轉訊息。 ......

    uj5u.com 2023-04-20 08:19:44 more
  • 露天煤礦現場調研和交流案例分享

    他們集團的資訊化公司及研究院在一個礦區正在做智能礦山的統一平臺的 試點,專案投資大概1億,包括了礦山的各方面的內容,顯示得我們這次交流有點多余。他們2年前開始做智能礦山的規劃,有很多煤礦行業專家的加持,他們的描述是非常完美,但是去年底應該上線的平臺,現在還沒有看到影子。他們確實有很多場景需求,但是被... ......

    uj5u.com 2023-04-20 08:19:07 more
  • 《社區人員管理》實戰案例設計&個人案例分享

    設計是一個讓人夢想成真程序,開始編碼、測驗、除錯之前進行需求分析和架構設計,才能保證關鍵方面都做正確 ......

    uj5u.com 2023-04-20 08:18:57 more
  • 軟體架構生態化-多角色交付的探索實踐

    作為一個技術架構師,不僅僅要緊跟行業技術趨勢,還要結合研發團隊現狀及痛點,探索新的交付方案。在日常中,你是否遇到如下問題 “ 業務需求排期長研發是瓶頸;非研發角色感受不到研發技改提效的變化;引入ISV 團隊又擔心質量和安全,培訓周期長“等等,基于此我們探索了一種新的技術體系及交付方案來解決如上問題。 ......

    uj5u.com 2023-04-20 08:18:49 more
  • 05單件模式

    #經典的單件模式 public class Singleton { private static Singleton uniqueInstance; //一個靜態變數持有Singleton類的唯一實體。 // 其他有用的實體變數寫在這里 //構造器宣告為私有,只有Singleton可以實體化這個類! ......

    uj5u.com 2023-04-19 08:42:51 more
  • 【架構與設計】常見微服務分層架構的區別和落地實踐

    軟體工程的方方面面都遵循一個最基本的道理:沒有銀彈,架構分層模型更是如此,每一種都有各自優缺點,所以請根據不同的業務場景,并遵循簡單、可演進這兩個重要的架構原則選擇合適的架構分層模型即可。 ......

    uj5u.com 2023-04-19 08:42:41 more