重新學習設計模式一：什麼是設計模式
- 2022 年 3 月 6 日
- 筆記
一直以來，設計模式是一個令人頭疼的課題，記得之前在A公司做智慧客服項目時，剛開始只是一個小項目，不管什麼設計模式，系統架構，全程直接上手敲業務程式碼，兩三天時間就把所有的程式碼敲完上線使用，結果誰也沒想到突然項目大起來了，十幾個業務部門的業務一擁而上，開始招人，上手業務，結果。。。大家都是苦力幹嘛，拚命加班，拚命填坑，十幾個人的程式碼亂七八糟，大量重複業務，重複程式碼，單簡單的一樣表單業務查詢就有三四不同的版本，新來的員工也在抱怨沒學到任何技術，倒學會怎麼跟業務吵架，那日子實在是不忍直視。。。
設計模式是什麼？這個是老生常談的問題了，它並不是教人如何設計用戶介面，怎麼學習程式語言，也不是告訴你什麼是面向對象資料庫等方法。設計模式是一套可以被反覆使用、多數人知曉的、經過分類編目的、程式碼設計經驗的總結。在軟體設計過程中可以設計成解決一些不斷重複的業務，以及該問題的解決方案。也就是說，它是解決特定問題的一系列套路(比如太極拳套路等)，是前輩們的程式碼設計經驗的總結，具有一定的普遍性，可以反覆使用。這樣做的目的是為了提高程式碼的可重用性、程式碼的可讀性，程式的可維護性和程式碼的可靠性。
通過學習理解設計模式有以下三個收穫：
- 提高編程思維：可以提高我們的編程思維能力、編程理解能力和設計程式的能力。
- 程式設計標準化：可以讓我們的程式設計更加標準化、程式碼編寫工程化、提高開發效率、從而縮短軟體的開發周期
- 程式碼易於理解：好的設計模式可以使程式碼設計的可重用性高、可讀性強、可靠性高。程式碼結構更靈活、易於維護。
總的來說，設計模式只是一個引導。在實際的軟體開發中，我們必須根據系統架構的應用程式特點恰當選擇合適的設計模式。對於簡單的程式，簡單的業務場景，只需要一個簡單的數據結構就可以解決的業務，沒必要在上面花太多時間，簡單的事情簡單處理。但對於大型項目的開發或框架設計，用設計模式來設計程式碼，那肯定是上上策，必須選擇設計模式。
對於每個標準來說，都有自己的基本要素，我們要了解明白設計模式的基本要素，這樣我們就可以跟設計者有共同語言交流，設計模式通常有幾個基本要素，比如：模式名稱、別名、動機、問題、解決方案、效果、結構、模式角色、合作關係、實現方法、適用性、已知應用、常式、模式擴展和相關模式等，其中著名的GoF列舉其中的四大要素：
- 模式名稱：這只是一個代記詞，就跟我們的人名一樣，便於記憶，一個好的名稱可以通過名稱了解模式的問題、解決方案和效果，也可以幫忙我們思考，便於我們與其他人交流設計思路及設計結果，取一個恰當的模式名就跟我們平時寫程式碼取一個好的方法及類一樣，不是那麼容易
- 問題(or 使用場景)：問題是描述我們在何時什麼場景使用這個模式，它必須解釋了設計問題(場景)或問題(場景)存在的前因後果，也可能描述了特定場景的設計思路、一種設計必須基於一個或多個問題 or 場景而設計的，這部分是設計模式中不可或缺的條件
- 解決方案：有了問題，就要有解決方案，我們了解到的模式就類似一個模板，解決某個問題或場景的模板，那麼模板就有具體的設計或實現方式。解決方案就是針對這個問題 or 場景的一種設計組成部分，可以用於多種場合，它的思路並不只針對於特定的問題而設計或實現的，可以使用同類或相似的問題場景，而是提供設計問題的抽象描述和怎麼用一個具有一般語義的元素組合(java語言中的類或對象組合)來解決這個問題。
- 效果：有了問題，有解決方案，當然要有解決方案的效果，總不能說我這個解決方案很厲害，但對於這個問題，效果不好，這不是扯淡嗎？效果一般都是從兩個方面來描述：優點、缺點。模式效果描述了模式應用的效果及使用模式應權衡的問題，對於評價一個設計選擇和理解使用模式的代價及好處是非常有意義的，軟體的大多數比較關注對時間和空間的衡量，也是表達了語言和實現問題效果。這對系統的靈活性、擴充性或可移植性有一定的影響。
以上是我個人對於重溫設計模式的看法，當然每個人思考問題的方式不一樣，出發點不同，會產生對於設計模式的理解不一樣，一個人設計出來的程式對於另一個人來說只是基本思路，基本構造部分而已，有時間大家可以一起交流探討。
