程序員為什麼要學設計模式

為什麼要學設計模式？

• 面試經常被問到
• 以前總覺得設計模式是“花拳繡腿”，實際開發中沒什麼卵用，其實有好多種設計模式自己在無形中就使用了，只是自己不知道
• 設計模式是軟件開發人員的“標準詞彙”，學習設計模式是個人技術能力提高的捷徑
• 設計模式包含了面向對象的精髓，“懂了設計模式，你就懂了面向對象分析和設計（OOA/D）的精要”

軟件設計模式概述

軟件設計模式的產生背景

“設計模式”這個術語最初並不是出現在軟件設計中，而是被用於建築領域的設計中。

1987 年，肯特·貝克（Kent Beck）和沃德·坎寧安（Ward Cunningham）首先將建築領域的模式思想應用在 Smalltalk 中的圖形用戶接口的生成中，但沒有引起軟件界的關注。

1994 年，艾瑞克·伽馬（ErichGamma）、理査德·海爾姆（Richard Helm）、拉爾夫·約翰森（Ralph Johnson）、約翰·威利斯迪斯（John Vlissides）等 4 位作者合作出版了《設計模式：可複用面向對象軟件的基礎》（Design Patterns: Elements of Reusable Object-Oriented Software）一書，在本教程中收錄了 23 個設計模式，這是設計模式領域裡程碑的事件，導致了軟件設計模式的突破。這 4 位作者在軟件開發領域裡也以他們的“四人組”（Gang of Four，GoF）匿名著稱。

軟件設計模式的概念與意義

1. 軟件設計模式的概念

軟件設計模式（Software Design Pattern），又稱設計模式，是指在軟件開發中，經過驗證的，用於解決在特定環境下、重複出現的、特定問題的

2. 學習設計模式的意義

設計模式的本質是面向對象設計原則的實際運用，是對類的封裝性、繼承性和多態性以及類的關聯關係和組合關係的充分理解。正確使用設計模式具有以下優點。

• 可以提高程序員的思維能力、編程能力和設計能力。
• 使程序設計更加標準化、代碼編制更加工程化，使軟件開發效率大大提高，從而縮短軟件的開發週期。
• 使設計的代碼可重用性高、可讀性強、可靠性高、靈活性好、可維護性強。

軟件設計模式的基本要素

軟件設計模式使人們可以更加簡單方便地複用成功的設計和體系結構，它通常包含以下幾個基本要素：模式名稱、別名、動機、問題、解決方案、效果、結構、模式角色、合作關係、實現方法、適用性、已知應用、例程、模式擴展和相關模式等，其中最關鍵的元素包括以下 4 個主要部分。

1. 模式名稱

每一個模式都有自己的名字，通常用一兩個詞來描述，可以根據模式的問題、特點、解決方案、功能和效果來命名。

2. 問題

問題（Problem）描述了該模式的應用環境，即何時使用該模式。它解釋了設計問題和問題存在的前因後果，以及必須滿足的一系列先決條件。

3. 解決方案

模式問題的解決方案（Solution）包括設計的組成成分、它們之間的相互關係及各自的職責和協作方式。因為模式就像一個模板，可應用於多種不同場合，所以解決方案並不描述一個特定而具體的設計或實現，而是提供設計問題的抽象描述和怎樣用一個具有一般意義的元素組合（類或對象的組合）來解決這個問題。

4. 效果

描述了模式的應用效果以及使用該模式應該權衡的問題，即模式的優缺點。主要是對時間和空間的衡量，以及該模式對系統的靈活性、擴充性、可移植性的影響，也考慮其實現問題。

GoF 的 23 種設計模式的分類和功能

1. 根據目的來分

根據模式是用來完成什麼工作來劃分，這種方式可分為創建型模式結構型模行為型模式

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

2. 根據作用範圍來分

根據模式是主要用於類上還是主要用於對象上來分，這種方式可分為類模式和對象模式

0. 類模式：用於處理類與子類之間的關係，這些關係通過繼承來建立，是靜態的，在編譯時刻便確定下來了。GoF中的工廠方法、（類）適配器、模板方法、解釋器屬於該模式。
1. 對象模式：用於處理對象之間的關係，這些關係可以通過組合或聚合來實現，在運行時刻是可以變化的，更具動態性。GoF 中除了以上 4 種，其他的都是對象模式。

23種設計模式的功能

0. 單例（Singleton）模式：某個類只能生成一個實例，該類提供了一個全局訪問點供外部獲取該實例，其拓展是有限多例模式。
1. 原型（Prototype）模式：將一個對象作為原型，通過對其進行復制而克隆出多個和原型類似的新實例。
2. 工廠方法（Factory Method）模式：定義一個用於創建產品的接口，由子類決定生產什麼產品。
3. 抽象工廠（AbstractFactory）模式：提供一個創建產品族的接口，其每個子類可以生產一系列相關的產品。
4. 建造者（Builder）模式：將一個複雜對象分解成多個相對簡單的部分，然後根據不同需要分別創建它們，最後構建成該複雜對象。
5. 代理（Proxy）模式：為某對象提供一種代理以控制對該對象的訪問。即客戶端通過代理間接地訪問該對象，從而限制、增強或修改該對象的一些特性。
6. 適配器（Adapter）模式：將一個類的接口轉換成客戶希望的另外一個接口，使得原本由於接口不兼容而不能一起工作的那些類能一起工作。
7. 橋接（Bridge）模式：將抽象與實現分離，使它們可以獨立變化。它是用組合關係代替繼承關係來實現，從而降低了抽象和實現這兩個可變維度的耦合度。
8. 裝飾（Decorator）模式：動態的給對象增加一些職責，即增加其額外的功能。
9. 外觀（Facade）模式：為多個複雜的子系統提供一個一致的接口，使這些子系統更加容易被訪問。
10. 享元（Flyweight）模式：運用共享技術來有效地支持大量細粒度對象的複用。
11. 組合（Composite）模式：將對象組合成樹狀層次結構，使用戶對單個對象和組合對象具有一致的訪問性。
12. 模板方法（TemplateMethod）模式：定義一個操作中的算法骨架，而將算法的一些步驟延遲到子類中，使得子類可以不改變該算法結構的情況下重定義該算法的某些特定步驟。
13. 策略（Strategy）模式：定義了一系列算法，並將每個算法封裝起來，使它們可以相互替換，且算法的改變不會影響使用算法的客戶。
14. 命令（Command）模式：將一個請求封裝為一個對象，使發出請求的責任和執行請求的責任分割開。
15. 職責鏈（Chain of Responsibility）模式：把請求從鏈中的一個對象傳到下一個對象，直到請求被響應為止。通過這種方式去除對象之間的耦合。
16. 狀態（State）模式：允許一個對象在其內部狀態發生改變時改變其行為能力。
17. 觀察者（Observer）模式：多個對象間存在一對多關係，當一個對象發生改變時，把這種改變通知給其他多個對象，從而影響其他對象的行為。
18. 中介者（Mediator）模式：定義一箇中介對象來簡化原有對象之間的交互關係，降低系統中對象間的耦合度，使原有對象之間不必相互瞭解。
19. 迭代器（Iterator）模式：提供一種方法來順序訪問聚合對象中的一系列數據，而不暴露聚合對象的內部表示。
20. 訪問者（Visitor）模式：在不改變集合元素的前提下，為一個集合中的每個元素提供多種訪問方式，即每個元素有多個訪問者對象訪問。
21. 備忘錄（Memento）模式：在不破壞封裝性的前提下，獲取並保存一個對象的內部狀態，以便以後恢復它。
22. 解釋器（Interpreter）模式：提供如何定義語言的文法，以及對語言句子的解釋方法，即解釋器。

設計模式七大原則

設計模式的目的

編寫軟件過程中，程序員面臨著來自耦合性，內聚性以及可維護性，可擴展性，重用性，靈活性等多方面的挑戰，設計模式是為了讓程序(軟件)，具有更好的

0. 代碼重用性 (即：相同功能的代碼，不用多次編寫)
1. 可讀性 (即：編程規範性, 便於其他程序員的閱讀和理解)
2. 可擴展性 (即：當需要增加新的功能時，非常的方便，稱為可維護)
3. 可靠性 (即：當我們增加新的功能後，對原來的功能沒有影響)
4. 使程序呈現高內聚，低耦合的特性

設計模式七大原則

設計模式原則，其實就是程序員在編程時，應當遵守的原則，也是各種設計模式的基礎(即：設計模式為什麼這樣設計的依據)

1. 單一職責原則

單一職責原則表示一個模塊的組成元素之間的功能相關性。從軟件變化的角度來看，對類來說，一個類應該只負責一項職責。

假設某個類 P 負責兩個不同的職責，職責 P1 和 職責 P2，那麼當職責 P1 需求發生改變而需要修改類 P，有可能會導致原來運行正常的職責 P2 功能發生故障。

單一職責原則注意事項和細節

0. 降低類的複雜度，一個類只負責一項職責
1. 提高類的可讀性，可維護性
2. 降低變更引起的風險
3. 通常情況下，我們應當遵守單一職責原則，只有邏輯足夠簡單，才可以在代碼級違反單一職責原則；只有類中方法數量足夠少，可以在方法級別保持單一職責原則

2. 接口隔離原則

客戶端不應該依賴它不需要的接口，即一個類對另一個類的依賴應該建立在最小的接口上

接口隔離原則，其 "隔離" 並不是準確的翻譯，真正的意圖是 “分離” 接口(的功能)

3. 開閉原則

開放-關閉原則表示軟件實體 (類、模塊、函數等等) 應該是可以被擴展的，但是不可被修改。(Open for extension, close for modification)

如果一個軟件能夠滿足 OCP 原則，那麼它將有兩項優點：

0. 能夠擴展已存在的系統，能夠提供新的功能滿足新的需求，因此該軟件有著很強的適應性和靈活性。
1. 已存在的模塊，特別是那些重要的抽象模塊，不需要被修改，那麼該軟件就有很強的穩定性和持久性。

4. 依賴倒轉(倒置)原則

依賴倒轉原則(Dependence Inversion Principle)是指：

0. 高層模塊不應該依賴低層模塊，二者都應該依賴其抽象
1. 抽象不應該依賴細節，細節應該依賴抽象
2. 依賴倒轉(倒置)的中心思想是面向接口編程
3. 依賴倒轉原則是基於這樣的設計理念：相對於細節的多變性，抽象的東西要穩定的多。以抽象為基礎搭建的架構比以細節為基礎的架構要穩定的多。在 java 中，抽象指的是接口或抽象類，細節就是具體的實現類
4. 使用接口或抽象類的目的是制定好規範，而不涉及任何具體的操作，把展現細節的任務交給他們的實現類去完成

5. 里氏替換原則

在編程中常常會遇到這樣的問題：有一功能 P1, 由類 A 完成，現需要將功能 P1 進行擴展，擴展後的功能為 P，其中P由原有功能P1與新功能P2組成。新功能P由類A的子類B來完成，則子類B在完成新功能P2的同時，有可能會導致原有功能P1發生故障。

里氏替換原則告訴我們，當使用繼承時候，類 B 繼承類 A 時，除添加新的方法完成新增功能 P2，儘量不要修改父類方法預期的行為。

里氏替換原則的重點在不影響原功能，而不是不覆蓋原方法。

6. 迪米特法則

0. 一個對象應該對其他對象保持最少的瞭解
1. 類與類關係越密切，耦合度越大
2. 迪米特法則(Demeter Principle)又叫最少知道原則
   ，即一個類對自己依賴的類知道的越少越好。也就是說，對於被依賴的類不管多麼複雜，都儘量將邏輯封裝在類的內部。對外除了提供的 public 方法，不對外洩露任何信息
3. 迪米特法則還有個更簡單的定義：只與直接的朋友通信
4. 直接的朋友：每個對象都會與其他對象有耦合關係，只要兩個對象之間有耦合關係，我們就說這兩個對象之間是朋友關係。耦合的方式很多，依賴，關聯，組合，聚合等。其中，我們稱出現成員變量，方法參數，方法返回值中的類為直接的朋友，而出現在局部變量中的類不是直接的朋友。也就是說，陌生的類最好不要以局部變量的形式出現在類的內部。

7. 合成複用原則

組合/聚合複用原則就是在一個新的對象裡面使用一些已有的對象，使之成為新對象的一部分; 新的對象通過向這些對象的委派達到複用已有功能的目的。

在面向對象的設計中，如果直接繼承基類，會破壞封裝，因為繼承將基類的實現細節暴露給子類；如果基類的實現發生了改變，則子類的實現也不得不改變；從基類繼承而來的實現是靜態的，不可能在運行時發生改變，沒有足夠的靈活性。於是就提出了組合/聚合複用原則，也就是在實際開發設計中，

學設計模式還得用大二學過的UML類圖，所以重新預習下。

UML

UML（Unified Modeling Language）是一種統一建模語言，為面向對象開發系統的產品進行說明、可視化、和編制文檔的一種標準語言

基於UML1.5 的UML種類

類圖

類圖（ClassDiagram）是用來顯示系統中的類、接口、協作以及它們之間的靜態結構和關係的一種靜態模型，是我們 Java 猿帥們最需要掌握的。它主要用於描述軟件系統的結構化設計，幫助人們簡化對軟件系統的理解，它是系統分析與設計階段的重要產物，也是系統編碼與測試的重要模型依據。 類圖中的類可以通過某種編程語言直接實現。類圖在軟件系統開發的整個生命週期都是有效的，它是面向對象系統的建模中最常見的圖。

類圖表示法

類之間的關係

在軟件系統中，類不是孤立存在的，類與類之間存在各種關係。根據類與類之間的耦合度從弱到強排列，UML 中的類圖有以下幾種關係：依賴關係、關聯關係、聚合關係、組合關係、泛化關係和實現關係。其中泛化和實現的耦合度相等，它們是最強的。

1. 依賴關係

只要在類中用到了對方，那麼他們之間存在依賴關係，依賴（Dependency）關係是一種使用關係，它是對象之間耦合度最弱的一種關聯方式，是臨時性的關聯。在代碼中，某個類的方法通過局部變量、方法的參數或者對靜態方法的調用來訪問另一個類（被依賴類）中的某些方法來完成一些職責。 在 UML 類圖中，依賴關係使用帶箭頭的虛線來表示，箭頭從使用類指向被依賴的類

2. 關聯關係

關聯（Association）關係是對象之間的一種引用關係，用於表示一類對象與另一類對象之間的聯繫，如老師和學生、師傅和徒弟、丈夫和妻子等。關聯關係是類與類之間最常用的一種關係，分為一般關聯關係、聚合關係和組合關係。

關聯具有導航性，即雙向關係和單向關係。

關聯具有多重性，如“1”表示有且僅有一個，“0..*”表示0個或多個。

單向關聯

雙向關聯

多重關聯

3. 聚合關係

聚合（Aggregation）關係表示的是整體和部分的關係，是 has-a 的關係，整體與部分可以分開，是關聯關係的特例，是強關聯關係。 聚合關係也是通過成員對象來實現的，其中成員對象是整體對象的一部分，但是成員對象可以脫離整體對象而獨立存在。例如，學校與老師的關係，學校包含老師，但如果學校停辦了，老師依然存在。

4.組合關係

組合（Composition）關係也是關聯關係的一種特例，也表示類之間的整體與部分的關係，但它是一種更強烈的聚合關係，不可以分開，是 cxmtains-a 關係。 在組合關係中，整體對象可以控制部分對象的生命週期，一旦整體對象不存在，部分對象也將不存在，部分對象不能脫離整體對象而存在。例如，公司和部門。

5.泛化關係

泛化（Generalization）關係是對象之間耦合度最大的一種關係，表示一般與特殊的關係，是父類與子類之間的關係，是一種

6.實現關係

實現（Realization）關係是接口與實現類之間的關係。在這種關係中，類實現了接口，類中的操作實現了接口中所聲明的所有的抽象操作。 在 UML 類圖中，實現關係使用帶空心三角箭頭的虛線來表示，箭頭從實現類指向接口。

參考

https://zhuanlan.zhihu.com/p/44518805

https://www.edrawsoft.cn/uml-diagram-introduction/

http://c.biancheng.net/view/1319.html

閱讀更多 派大新 的文章

關鍵字: 軟件設計 設計 Smalltalk