重用的兩條路徑 繼承：編譯期靜態綁定，是「是一種」關係； 組合：執行期動態組合，是「有一個」關係。 組合的優勢 特性繼承組合 耦合度高（破壞封裝，父類別

繼承的目標：克隆並擴充既有型別 建立新型別時，若能克隆既有型別並修改/擴充，比從零開始強太多。繼承正是為此設計： 關鍵字：extends； 新類別（子類別/衍

兩種繼承關係的本質差異 等價關係：純粹替換 衍生類別只覆寫、不新增介面； 衍生類別物件完美替換基底類別物件； 關係語意：「是一種」（Is-a）——「圓是一種

繼承體系最終形成統一介面的類別族群。向上轉型讓衍生類別物件視為基礎類別，實現「對介面程式設計，不對實作程式設計」。 向上轉型核心概念 void doStuff

現象：不知型別卻能正確呼叫 void doStuff(Shape s) { s.erase(); s.draw(); // s 可能是 Circ

抽象類別：只供繼承，不供實例化 當基底類別僅為衍生類別提供共同介面，不希望被直接實例化時，使用 abstract 關鍵字： abstract class Sha

核心問題：資料放哪？何時銷毀？ OOP 的核心在於抽象資料型別、繼承、多型，但物件如何建立、資料儲存位置、生命週期誰控制同樣關鍵。C++ 與 Java 採取截然

為什麼需要集合？ 解決問題時，我們往往無法預知需要多少物件、它們的存活時間。陣列雖能儲存物件，但大小固定、操作僵化。集合（Collection，又稱容器）應運而

什麼是單根結構？ 在面向對象程式設計（OOP）領域，關於「所有類別是否應繼承自單一基底類別」的爭論由來已久。C++ 讓這個問題浮上檯面，而 Java 給出的答案

集合庫必要性 集合為常用工具，需可重用庫 Java 提供此庫（1.0/1.1 有限，1.2 集合框架為傑作） 通用類型 Object 與向上轉型 單根結

核心問題 物件需資源（尤記憶體）生存 不再需要 → 必須清除釋放資源 簡單案例：建立→用完→刪除 複雜案例：多系統共享物件（機場管制、貨櫃、影帶出租） 複

歷史痛點 錯誤控制從最古老語言就是大問題 難設計完美方案 → 多語言忽略、拋給庫設計者 依賴程式設計師警覺性而非語言強制 → 匆忙時必失效 異常處理機制

核心需求 同時控制多任務 暫停當前工作處理其他問題 → 返回主流程 演進歷程 早期：硬體中斷服務例程 → 移植性差 即時任務仍需中斷 大多數問題：切分為

現狀與價值 物件預設：程式結束即銷毀 若能程式停止後繼續存在、保留所有資訊 → 某些情況極有價值 下次啟動物件仍在，資料為上次狀態 替代方案：手動寫檔案/資料

客戶/伺服器核心思想 資訊集中儲存（資料庫） 依請求投遞資訊 關鍵：集中 → 易修改、易分發 元件：資訊倉庫 + 投遞軟體 + 機器 = 伺服器 遠端機器軟體

背景：伺服器-瀏覽器模式局限 互動完全靠伺服器 → 負擔重 靜態 HTML + 簡單表單 + CGI 回傳 響應慢：拼寫錯誤需等秒/分才知 動態圖形幾乎無法連

伺服器端請求類型 簡單請求：「給我這個檔案」→ 瀏覽器解譯顯示 複雜請求：資料庫操作（事務處理） 典型流程 資料庫查詢 → 格式化為 HTML → 返回

定位澄清 爭論多集中於 Applet Java 實為通用程式語言，理論上解決任何問題 客戶端/伺服器問題可用更有效方式解決 應用程式特性 獨立執行，無需

核心挑戰 OOP 思維模式全新，許多人在如何構造專案上皺眉。事實上可作出充分發揮 OOP 優勢的好設計。 現有書籍痛點 多數不盡如人意 充斥莫名其妙術語、筆

第一步：決定步驟 聽起來簡單，但常見錯誤：甚至未進入階段一就狂寫代碼。 最低共識 若計畫就是「直接編碼」且對問題極透徹 → 可接受 但最低限度應同意「該有個