前言 當系統需要建立物件，但具體建立哪種類別、如何建立由子類別決定時，工廠方法模式提供標準方案：定義一個建立物件的介面（工廠方法），讓子類別決定實例化哪個類別。

前言 單例模式確保一個類別在整個應用程式生命週期中只有一個實例，並提供全域存取點。它是最基礎也最常被誤用的模式之一。本文深度解析單例模式的多種實現方式，從經典雙

前言 當需要使用現有類別，但其介面不符合當前系統需求時，適配器模式提供標準解決方案：將一個類別的介面轉換成客戶端期望的另一個介面。適配器模式分為「類別適配器」（

前言 當系統有兩個獨立變化的維度（如：訊息操作類型：基本/進階 × 儲存方式：SQL/XML/JSON/NoSQL）時，若用繼承組合會導致類別爆炸（基本SQL、

前言 當需要表示「部分-整體」層次結構（如：檔案系統目錄/檔案、組織架構部門/員工、UI 容器/控制項、圖形編輯器群組/圖元）時，客戶端往往需要統一處理單個物件

前言 當需要為物件動態添加職責，且希望比繼承更靈活、避免類別爆炸時，裝飾模式是首選：將物件包裝在裝飾者中，裝飾者實作相同介面，持有被裝飾物件參考，轉發呼叫並在前

前言 當系統包含多個相互依賴的子系統（如：驗證服務、資料存取、日誌、快取、通知）時，客戶端直接與各子系統交互會導致高耦合、使用複雜、測試困難。外觀模式提供一個統

前言 當系統需要建立大量相似的細粒度物件（如文字編輯器每個字元、遊戲每顆子彈、圖形編輯器每個圖元）時，每個物件獨立儲存所有狀態會導致記憶體耗盡。享元模式透過「共

前言 當需要控制對某個物件的存取、延遲昂貴物件的建立、記錄操作日誌、權限檢查、快取結果或遠端呼叫時，直接使用真實物件會導致客戶端程式碼混雜基礎設施邏輯。代理模式

前言 當一個請求可能由多個處理者處理，但發送者不明確知道由誰處理，且處理者集合動態變化時，責任鏈模式提供優雅方案：將處理者串成一條鏈，請求沿鏈傳遞，直到有處理者

前言 當系統需要支援「撤銷/重做」、操作佇列、請求日誌、巨集記錄、交易回滾等功能時，將請求封裝為獨立物件是關鍵。命令模式將「請求的發起者」與「請求的執行者」解耦

前言 當系統需要處理特定領域的語法規則（如數學表達式、規則引擎、查詢語言、配置腳本）時，硬編碼解析邏輯會導致系統僵化、難以擴展。解釋器模式提供一種建構「語言解釋

前言 在軟體開發中，集合類別（陣列、列表、樹、圖）內部結構各異，但客戶端常需以統一方式順序存取元素。若暴露集合內部結構（如索引、節點指標），會導致客戶端與集合緊

前言 在複雜系統中，多個物件之間往往存在錯綜複雜的相互引用與通訊關係：A 呼叫 B、B 通知 C、C 又回調 A……這種「網狀耦合」導致系統難以維護、擴展與測試

前言 在軟體開發中，我們常需要提供「復原」功能：使用者編輯文件時可隨時撤銷、遊戲角色狀態可存檔讀檔、資料庫交易失敗需回滾。直接暴露物件內部狀態違反封裝性；複製整

前言 當一個物件的行為取決於其內部狀態，且必須在運行時根據狀態改變其行為時，傳統做法是在方法中使用大量 if-else 或 switch 判斷狀態，導致程式碼龐

前言 當系統需要在執行時根據條件動態切換演算法或行為時，若使用大量 if-else 或 switch-case 判斷，會導致程式碼難以維护、違反開閉原則。策略模

前言 在開發過程中，我們常遇到一類問題：演算法的整體流程固定，但某些步驟的具體實作因子系統而異。例如「先驗證權限，再查詢資料」，驗證邏輯固定，查詢來源可能是 S

前言 在軟體開發中，當我們需要對一個複雜的物件結構執行各種操作，且這些操作會頻繁變動或新增時，若直接在物件類別中添加方法，會違反「開閉原則」並導致類別膨脹。訪問

模式意圖 將抽象契約與具體實現分離，通過配置文件動態載入提供者，實現儲存介質（SQL Server / XML / 其他）的熱插拔。 領域模型 public