七項循序漸進的實作練習 移除緩衝機制：編譯執行 JabberServer/Client，移除所有輸入輸出緩衝，觀察行為差異。 密碼保護檔案傳輸：撰寫伺服器驗證

本章學習目標 介紹「設計模式」這一重要且非傳統的程式設計方法論。源自 Gamma、Helm、Johnson、Vlissides 合著的《Design Patte

模式的本質：聰明且自適應的解決方案 設計模式不只是程式碼範本，而是針對特定問題、經過充分理解後提煉出的最通用、最靈活方案。它超越傳統分析/設計/實作的階段界限，

核心做法：私有建構子與靜態存取點 單例模式透過將建構子設為 private，防止外部直接實例化；提供 public static 方法（如 getHandle(

《設計模式》的 23 種模式分類標準 書中依據「可能發生變化的方面」將 23 種模式分為三類： 1. 創建型模式 關注物件的建立方式，隔離建立細節，使系統不依

模式動機：狀態變更的自動通知 觀察者模式解決「一組物件需在另一物件狀態改變時自動更新」的問題。典型場景如 MVC 的 Model-View、文檔-視圖架構。Ja

問題情境：混雜垃圾的分類挑戰 垃圾進入回收站時是混雜的，程式必須在缺乏型別資訊的情況下正確分類。初版 RecycleA 使用 RTTI（執行期型別識別）實現：將

核心觀點 《設計模式》一書的所有方案都圍繞「程式演進時會發生什麼變化」這一核心問題。這也是任何軟體設計最關鍵的問題。若能根據此問題的答案構建系統，將獲得雙重收益

設計原則：複雜時就製造更多物件 Grady Booch 提出的經典原則——「若設計過於複雜，就製造更多的物件」，是解決物件建立混亂的良方。在垃圾回收範例中，ma

原型模式解決工廠方法的擴充難題 在先前的工廠方法設計中，factory() 方法集中管理所有具體類型的建立邏輯。每當系統需要新增一種垃圾類型（如 Cardboa

設計演進：從暴露分類到封裝區域化 分類邏輯暴露不雅且過度揭露。規則：「如果必須做不雅的事，至少將其本地化到一個類裡」。引入 TrashSorter 封裝分類。初

現有方案評估與更純粹目標 前方案令人滿意：新類型加入涉及添加/修改不同類別，無需大範圍代碼變動，RTTI 未濫用。但仍可更深入，以最「純」角度看待 RTTI，考

雙重分派核心原理 多型只能透過方法調用表現，雙重分派需執行兩次方法調用：各結構各一次判斷類型。Trash 結構使用 addToBin(TypedBin[] tb

訪問者模式適用場景 不再關心新增 Trash 類型優化。假設基礎類結構固定不變（來自他開發者/公司，無權修改），但希望在結構中新增多型方法。困境：需向基礎類添加

RTTI 爭議與誤解 本章各設計方案努力避免使用 RTTI，可能留下「RTTI 有害」印象（如可憐的 goto 因印象不佳未入 Java）。實際情況非絕對：錯誤

設計模式的核心價值 從表面看，TrashVisitor.java 等模式包含更多代碼，留下效率不高印象。但關鍵在於達到什麼目的。設計模式特別適合「將發生變化的東

C/C++ 開發者的疑慮與現實 有 C/C++ 經驗者可能懷疑 Java 控制文字能力，最擔心速度極慢阻礙創造力發揮。事實上，Java 對應工具（特別是 Str

工具設計背景與標記規範 本書每個完整代碼列表以特殊註釋標記起始（//:）與結束（///:~），便於自動提取至相容源碼檔案。前作採用自動合併測試代碼入書，本書採測

前言 統一的程式碼風格是團隊協作的基石。Java 慣例規定類名首字母大寫、變數與方法名採用駝峰式小寫開頭。本文介紹一個實用工具 ClassScanner，能自動

工具演進與改進 第 11 章介紹 Java 1.1「反射」概念查詢類別方法。原例為純命令列應用，未使用 AWT。本工具改進為 GUI 版本：輸入字符時自動刷新輸