設計模式的核心精神貫穿一個根本原則：面向介面編程，而非面向實現。這意味著在物件導向開發中，我們應依賴抽象（介面）而非具體類別，以降低模組間的耦合度，提升系統的靈活性與可維護性。
工廠模式的使用頻率堪比 new 關鍵字。它將物件的實例化邏輯封裝於工廠類中，客戶端無需知曉具體類別名稱，即可透過統一介面獲取所需物件，實現了解耦。
透過原型實例指定創建物件的種類，並通過拷貝這些原型來創建新物件。適用於初始化成本高、且新物件與原型差異較小的場景。
以組裝汽車為例：車輪、方向盤、引擎等零件構造複雜，組裝過程亦非易事。建造者模式將「構造零件」與「組裝流程」分離，使相同的構建過程能創建不同表示的產品。
確保一個類別在全域僅有一個實例，並提供一個全域存取點。常用於資源共享（如連線池、配置管理器）的場景。
為子系統提供一個統一的高層介面，降低客戶端與子系統的耦合。例如在 JDBC 程式設計中，Facade 可屏蔽不同資料庫的差異，提供靈活的存取方式。
為其他物件提供一個代理以控制對其的存取。以 Jive 為例，剖析了代理模式在使用者層級授權機制中的應用。
將一個類別的介面轉換為客戶端期望的另一個介面。類別複用的兩種方式——組合與繼承——在此均有體現。
將物件組合成樹狀結構以表示「部分-整體」層次。客戶端對單個物件與組合物件的操作保持一致，如同個體與集團的關係。
動態地給物件添加額外職責，如同油漆工為牆面增色，在不改變原有結構的前提下擴展功能。
將抽象與實現分離（如牛郎織女），使它們可以獨立變化，再透過一座橋樑（介面）動態結合。
運用共享技術有效支援大量細粒度物件的復用，降低記憶體開銷，提升 Java 執行效能。
定義演算法骨架，將某些步驟延遲到子類別實現。深刻闡述了為何使用 Java 抽象類，原理簡單卻應用極廣。
在不破壞封裝性的前提下，捕獲並外部化物件的內部狀態，以便日後恢復。本質上是在記憶體中保留資料拷貝。
定義物件間一對多的依賴關係，當主題狀態改變時，所有觀察者均會收到通知。介紹了如何使用 Java API 內建的 Observer 機制。
將處理請求的物件串成一條鏈，請求沿鏈傳遞直到有物件處理它。猶如擊鼓傳花，若當前節點能處理則不再傳遞。
將請求封裝為物件，從而使您可用不同的請求對客戶端進行參數化，支援佇列、日誌、撤銷等操作。是「行為封裝」的典範。
允許物件在內部狀態改變時改變其行為。將狀態物件化，設立狀態轉換器，使狀態切換輕鬆自然。
定義一系列演算法，分別封裝並使它們可互換。客戶端可根據需求靈活選擇所需演算法。
用一個中介物件封裝一系列物件間的交互。如同十字路口的紅綠燈，各車輛（同事物件）只需與紅綠燈（中介者）互動，無需直接耦合。
給定一門語言，定義其文法的表示，並定義一個解釋器。主要用於語言分析，實際應用機會相對較少。
表示一個作用於某物件結構中各元素的操作。訪問者在訪問時完成實質操作，且易於擴展新操作而不修改元素類別。
提供一種方法順序存取聚合物件中的各元素，而無需暴露其內部表示。在 Java 中已內建於 Collection 框架，使用頻率極高，開發者無需自行實作。
