深入淺出設計模式① —— 設計模式之路

文章目錄

• • 1.前言
  • 2.設計模式劃分
    • 2.1 根據模式的目的劃分
      • 2.1.1 建立型模式
      • 2.1.2 結構型模式
      • 2.1.3 行為型模式
    • 2.2 根據模式的作用劃分
      • 2.2.1 類模式
      • 2.2.2 對象模式
  • 3.總結

    部落客經過6年的代碼洗禮，慢慢意識到代碼中使用設計模式的重要性。然而，在我遇到的程式員大軍中，我大概歸類了以下幾類人：

• A類：完全沒有考慮設計模式，代碼完全ctrl C+ctrl V，一般是大學生居中；
• B類：聽過設計模式，但是覺得深奧，不考慮入門，工作一兩年的初級工程師；
• C類：合理性使用設計模式，代碼維護度和擴充度很高，這是我所追求的方向。

    是以，部落客計劃做一個設計模式的系列文章，記錄學習筆記，力求深入淺出設計模式。

    如果你有以下幾種想法（一個有追求的程式員），我非常建議學習設計模式：

• 架構設計時，如何實作高内聚低耦合？
• 面對産品人員提出的需求變更，我如何盡量以最少的代碼改動完成任務，并且不應該舊業務？
• 如何在團隊協作中沉澱出可複用元件，如何解耦？

    這裡先推薦幾本部落客閱讀的設計模式書籍：

• 大話設計模式（小白推薦）
• Head First 設計模式（中文版）（小白推薦）

• 設計模式之禅（第2版）（部落客極度推薦，快速看完上面小白入門可以看這個）

      請記住，設計模式并不是憑空出現，而是程式員在不斷地開發以及優化功能的過程中總結出的寶貴代碼設計精華，用來應對各種業務需求。

    目前有23種設計模式。設計模式有兩種分類方法，一種是根據模式的目的來劃分，另一種根據模式的作用範圍來劃分。

    根據模式是用來完成什麼樣的工作，可以劃分為：

• 建立型模式
• 結構型模式
• 行為型模式

建立型模式用來描述“怎麼建立對象，對象從哪裡擷取”。主要是為了将對象的建立與使用分離。包括5大模式：

• 單例模式
• 工廠方法模式
• 抽象工廠模式
• 原型模式
• 建造者模式

請記住：着重于對象如何建立，從哪裡建立

結構型模式用來描述“處理類和對象的組合，将類和對象按照某種布局完成更大的結構”。包括7大模式：

• 擴充卡模式
• 橋接模式
• 組合模式
• 裝飾模式
• 外觀模式
• 享元模式
• 代理模式

請記住：着重于對象與對象之間的一種關系、布局、結構

行為型模式用于描述“類或對象之間怎樣互相協作共同完成單個對象無法單獨完成的任務，以及怎樣配置設定職責”。包括11種：

• 模闆方法模式
• 解釋器模式
• 政策模式
• 指令模式
• 責任鍊模式
• 狀态模式
• 觀察者模式
• 中介者模式
• 疊代器模式
• 通路者模式
• 備忘錄模式

請記住：着重于對象為了完成某個行為而協作的過程，重點在于行為

    根據模式用于類上還是對象上來分，這種方式可分為：

• 類模式
• 對象模式

用于處理類與子類之間的關系，這些關系通過繼承來建立，是靜态的，在編譯時便确定下來了。

• 擴充卡模式（類）

使用者處理對象之間關系的，這些關系可以通過組合或聚合來實作，在運作時刻是可以變化的，更具動态性。除了上面四個模式之外，其他模式都是屬于對象模式（擴充卡模式比較特别）。

綜合總結為下圖：

當然，請記住，不要為了使用設計模式而去使用模式（這種叫做過度設計）。

本篇沒有太多的技術難點，主要是抛磚引玉，引入設計模式的概念，以及設計模式的劃分。讓大家有個初步的概念。請繼續關注後面的博文，部落客會在博文中講解實際項目中是如何使用的。

在做小項目的時候，可以不考慮設計模式，因為有時候引入設計模式可能會額外添加更多的代碼，不要讓代碼為設計模式服務，這是本末倒置的。

在做大項目（多人協作項目，逐漸疊代的項目）的時候，部落客極度建議适度考慮設計模式，因為涉及到後期的産品疊代開發，往往有意向不到的需求變更。當一個代碼随着需求的變更而不用修改太多舊邏輯代碼的時候，我覺得這就是一個成功的代碼。

• 在涉及到建立對象的過程，可以考慮建立型設計模式
• 在涉及對象與對象之間的關系時，可以考慮結構型設計模式
• 在考慮如何增強對象行為或者對象無法單獨完成某個任務時，可以考慮行為型設計模式。