為什麼前端的我要學design pattern呢？
因為我發現沒有學過的話，我會對軟體的系統設計沒有甚麼概念，尤其是剛進新公司，或是接手了新專案，有很多不同的程式語言、架構和其他問題，很難弄清楚從哪裡開始。這就是設計模式派上用場的地方。

設計模式就像專案的模板，擁有規範章程，可以預設規範特定類型的行為。這些模式是由許多開發人員的經驗累積，因此它們實際上就像是不同的設計範例。

我們可以決定要選哪一種範例對我們的專案最適用。根據我們選擇的設計模式，將開始對專案流程進行畫面、程式邏輯的設計。

《 Design Patterns - Elements of Reusable Object-Oriented Software》一書中有 23 個官方模式，該書被認為是面向對象理論和軟件開發最有影響力的書籍之一。

先來了解維基百科對design pattern的定義。

設計模式（design pattern）

在軟體工程中，design pattern是對軟體設計中普遍存在的各種問題，所提出的解決方案。這個術語是由Erich Gamma等人在1990年代從建築設計領域引入到計算機科學的。

設計模式並不直接用來完成程式碼的編寫，而是描述在各種不同情況下，要怎麼解決問題的一種方案。物件導向設計模式通常以類別或物件來描述其中的關係和相互作用，但不涉及用來完成應用程式的特定類別或物件。設計模式能使不穩定依賴於相對穩定、具體依賴於相對抽象，避免會引起麻煩，以增強軟體設計面對並適應變化的能力。

表述一個軟體設計模式的格式根據作者的不同，劃分和名稱等都會有所不同。常用的GoF描述模式的格式大致分為以下這些部分：

• 模式名：每一個模式都有自己的名字，模式的名字使得我們可以討論我們的設計。
• 問題：在物件導向的系統設計過程中反覆出現的特定場合，它導致我們採用某個模式。
• 解決方案：上述問題的解決方案，其內容給出了設計的各個組成部分，它們之間的關係、職責劃分和協同運作方式。
• 別名：一個模式可以有超過一個以上的名稱。這些名稱應該要在這一節註明。
• 動機：在哪種情況使用該模式，是本節提供的方案（包括問題與來龍去脈）的責任。
• 適用性：模式適用於哪些情況、模式的背景等等。
• 結構：這部分常用類圖與互動圖闡述此模式。
• 參與者：這部分提供一份本模式用到的類與物件清單，與它們在設計下扮演的角色。
• 合作：描述在此模式下，類與物件間的互動。
• 影響：採用該模式對軟體系統其他部分的影響，比如對系統的擴充性、可移植性的影響。影響也包括負面的影響。這部分應描述使用本模式後的結果、副作用、與權衡(trade-off)。
• 實作：這部分應描述實現該模式、該模式的部分方案、實現該模式的可能技術、或者建議實現模式的方法。
• 範例：簡略描繪出如何以程式語言來使用模式。
• 已知應用：業界已知的實作範例。
• 相關模式：這部分包括其他相關模式，以及與其他類似模式的不同。

看完上方的簡介，其實就會有大略的專案雛形，只要依據上方列出內容，去一一拆解，最一開始需要選擇適合你專案的模式，找出我們會面對的問題，如何提供解決方案，設計的動機，有哪些適用的背景、情況，結構就類似功能地圖，參與者就是參與專案每個人的角色位置，若選定某模式後，對這個軟體設計會有哪些影響和副作用，找出最可能實作的模式，或找出業界類似的範例，下一篇繼續來介紹軟體設計會用到的design pattern有哪些？

參考資料：
設計模式 (電腦)

這是我第一次參加鐵人賽，希望透過這30天督促自己脫離菜味，內容預計會有JS基礎，API串接，用React完成一個可以新增、修改、刪除、查詢的網站，如果有錯誤歡迎指正，我會盡快修改。