設計模式(design pattern)的概念起源於建築師 Christopher Alexander，他記錄了解決設計問題的經驗，隨後與 Sara Ishikawa 和 Murray Silverstein 合作開發一種模式語言，並在 1977 年〈A Pattern Language〉的論文中發表，在此篇論文中，Alexander 這樣描述模式：「每個模式都描述了在我們的環境中反覆出現的問題，然後描述了該問題解決方案的核心，以便你可以使用該解決方案一百萬次，而無需以相同的方式執行兩次。」(Alexander, 2018)
而其實當時的程式設計領域一直有設計模式的概念，只是不太正式，後來在 1990 年左右，軟體工程師開始將 Alexander 所提的原則納入設計模式說明文件。1995 年，Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides 四人出版了第一本軟體工程設計模式《Design Patterns: Elements of Reusable Object-Oriented Software》(Gamma et al., 1995)，書中提出 23 種經典設計模式，是至今仍最具標誌性的著作，而四位作者也被稱為四人幫(Gang of Four，簡稱 GoF)。有時我們會以 GoF 來代指《Design Patterns: Elements of Reusable Object-Oriented Software》這本書。
在 GoF 提出軟體工程設計模式後，設計模式也逐漸在軟體工程領域中蓬勃發展，大量書籍、期刊文章或網站呈現了各種模式以解決軟體系統中反覆出現的問題，許多人會以模式記錄或交流系統開發任務的專業知識，例如設計、分析、測試與專案管理。
軟體工程中的設計模式是描述一個在特定情境裡經常發生的設計問題，並提供通用解決方案的方式，模式會提取過去例子中的關鍵部分，將其抽象化為一種大家能共同理解的語言，日後有人遇到類似問題，可根據特定需求調整解法，但解決方案的核心可作為參考指南。
模式主要由情境、問題和解決方案三要素組成，下圖說明它們的關係。模式會先描述問題的情境，接著說明問題及其權衡(forces)。權衡指解決問題時要考慮的各種面向，可能互補或矛盾。權衡分三類：需求(必須滿足的要素)、限制(設計時必須考量的限制，例如特定協議)、理想屬性(解法應有的特性)。在解決方案中會描述如何解決問題並平衡這些權衡，說明元素的架構與關聯、執行時機與流程。然而，解法可能無法完全解決所有權衡，有時會集中解決特定權衡，而留下其他未解決或半解決。
圖 1 模式的組成要素(資料來源：自行繪製)
撰寫模式時，通常會遵循特定結構來撰寫，以便開發者快速理解模式用途與解決方案。下表列出可敘述模式的項目，包含模式名稱、結構、動態性、實踐、實施模式的結果、相似問題的其他模式等：
表 1 描述模式的項目(資料來源：Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., & Stal, M. (1996). Pattern-Oriented Software Architecture - Volume 1: A System of Patterns: Wiley Publishing.)
| 描述模式的項目 | 說明 |
|---|---|
| 模式名稱(Name) | 為模式命名，名字通常要簡短、直覺且一目了然 |
| 其他名稱(Also known as) | 若模式有其他名字或稱呼方式也可補充 |
| 例子(Example) | 描述真實世界的例子，可在其中闡述問題以及模式的必要性。描述模式時會參考例子來說明解決方案及實踐面向。 |
| 情境(Context) | 模式要應用的情境 |
| 問題(Problem) | 模式要解決的問題，包含對權衡(forces)的討論 |
| 解決方案(Solution) | 模式背後的基本解決原則 |
| 架構(Structure) | 模式結構面的詳細規範 |
| 動態性(Dynamics) | 模式運行時(run-time)的行為，可使用UML循序圖(Sequence Diagram)描述 |
| 實踐(Implementation) | 實踐模式的指南，通常會補充不同的、更詳細的步驟，或重新排序這些步驟以滿足需求。有時會補充程式碼片段說明實踐細節 |
| 例子其他面向(Example Resolved) | 討論例子中仍未被解決的面向 |
| 變體(Variants) | 簡要描述模式的變體或特殊情況，此處提供不同解法的選擇 |
| 他人應用(Known uses) | 利用現有系統提出模式的使用範例 |
| 結果(Consequences) | 模式提供的好處以及潛在缺點 |
| 其他參考(See Also) | 參考解決相似問題的模式，以及幫助完善此模式的其他模式 |
其中，模式名稱、情境、問題、解決方案是描述模式時較重要的要素，因此之後提到不同模式時，我也會盡量以這些要素來介紹模式。
設計模式依據解決的問題類型，可分為：
今天簡單介紹了模式是什麼，因為之前研究所論文讀過 pattern 的相關資料，就一起整理上來了><，用一句話總結的話，模式就是針對反覆出現的問題所提出的解決方案，但不是具體程式碼解法，而是一個綱要/指南，實際實作時仍須配合開發者當下情況來判斷~
iThome鐵人賽
看影片追技術