設計模式筆記總覽
2026年7月18日 晚上7:10 · 更新於 2026年8月10日 下午3:48 · 閱讀 3 分鐘
系列文章： 常用設計模式整理 （第 1 篇）
楔子
在軟體世界裡，開發者們有無限的自由。撰寫程式的過程就像用樂高拼出一台汽車，要選擇什麼形狀、什麼大小的積木，積木之間要如何堆砌，都可以自由決定。每個人建造出的車子功能都差不多，但內部結構則各有巧思。但如果今天想拼湊的不是車，而是一整座城市怎麼辦？直接靠眼前的一塊塊積木蓋出整個台北市？
聽起來蠻難的，但好險我們現實生活中早已經有人很懂得如何建築住宅，有人擅長劃設道路，還有人專門做整個都市的規劃 —— 這就是「設計模式」的概念了。如果說變數、函式、迴圈等程式語法是積木本身，那設計模式就是告訴我們要怎麼建造一座橋、怎麼做都市規劃。設計模式是對於軟體設計常見問題的參考解答。
學習設計模式，除了在面對到類似問題時可以抄答案快速應對，同時也是種開發者之間的共通語言。當你看到了熟悉的設計模式的影子，就能夠更快掌握他人撰寫的程式碼的邏輯。
工程師如何讓鴿子飛起來
開發守則：If it works don’t touch it
預計介紹的設計模式
此系列文中，依據個人的主觀喜好與熟悉程度，將依序介紹幾個常用的設計模式：
- Strategy Pattern
- Adapter Pattern
- Chain of Responsibility Pattern
- Singleton Pattern
- Factory Method Pattern
- Builder Pattern
- Observer Pattern
學習之前打點預防針
設計模式不是完美無缺
- 常見 Trade-Off：彈性與包裝 vs. 精簡與效率
適當應用設計模式可以讓系統變得更具彈性，讓未來更容易擴充新功能，或可以讓溝通的介面變得更簡單好懂。但這樣的彈性或邏輯簡化也是有代價的，實踐方式往往會引入新的類別或是新的介面，程式架構通常會更龐大，由於各種介面的間接溝通也可能導致執行速度變慢。
如果未來系統需求其實不太常需要擴充，那用最簡單的 if-else 之類的也可能是最合適的解法。
沒辦法什麼都用設計模式
設計模式只提供「常見」問題的解法，無法讓所有情景都適用。若情境不適合而硬套設計模式的話，反而只是引入不必要的複雜度。