在軟體工程的領域中，語言的精確性決定了實現的精確性。物件導向分析與設計（OOAD）依賴於特定的詞彙來描述系統如何運作、資料如何結構化，以及組件之間如何互動。若缺乏對這些術語的共同理解，利益相關者、分析師與開發人員之間的溝通將陷入混亂。本指南概述了構成現代軟體架構核心基礎的基本概念。
🏗️ 核心構建模塊：類別與物件
在深入複雜關係之前，必須先理解結構的基本單元。OOAD將資料與行為視為一個整體。
- 類別： 用來建立物件的藍圖或範本。它定義了物件所具備的狀態（屬性）與行為（方法）。可將其視為房屋的建築設計圖，而非房屋本身。
- 物件： 類別的一個實例。當類別被實例化時，會配置記憶體來儲存該物件的特定資料。若類別是藍圖，則物件就是根據該計畫所建造的實際建築。
- 屬性： 亦稱為屬性或欄位，用以表示物件內部所持有的狀態或資料。範例包括使用者姓名、帳戶餘額或產品價格。
- 方法： 與物件相關的函式或程序，用以定義其行為。方法使物件能夠執行動作，例如計算總額或發送通知。
- 建構函式： 當物件被建立時會被呼叫的特殊方法。它將物件的狀態初始化為一個有效的起始點。
- 解構函式： 當物件被銷毀時會被呼叫的方法。它負責處理清理工作，例如釋放記憶體或關閉檔案連接。
🧩 物件導向的四大支柱
這四項原則使物件導向系統與程序式系統區別開來。理解此區別對於設計彈性且可維護的軟體至關重要。
1. 抽象 🧠
抽象涉及隱藏複雜的實作細節，僅呈現物件的必要功能。它讓開發者能夠專注於做什麼物件做什麼，而非如何它如何完成。
- 介面： 一種合約，定義了一組類別必須實作的方法，但不提供實作細節。
- 抽象類別： 一種無法獨立實例化的類別，旨在被繼承。它可同時包含抽象方法（無主體）與具體方法（有主體）。
2. 封裝 🔒
封裝將資料與方法結合在一起，同時限制對物件部分元件的直接存取。這可保護內部狀態免受外部干擾。
- 存取修飾詞：控制可見性的規則。常見類型包括：
- 公開：可從任何其他類別存取。
- 私有：僅可在定義類別內存取。
- 保護：可在類別及其子類別中存取。
- 取得器/設定器：用於安全地讀取或修改私有屬性的方法。
3. 繼承 🌳
繼承允許新類別取得現有類別的屬性和行為。這促進了程式碼重用，並建立層次關係。
- 父類別/超類別：被繼承的類別。
- 子類別/子類別：從父類別繼承的類別。
- 方法覆蓋：當子類別提供其父類別中已定義的方法的特定實作時。
4. 多型性 🔄
多型性允許不同類別的物件被視為共同超類別的物件。它使同一介面可用於一類通用操作。
- 編譯時期多型性：透過方法重載實現，多個方法共享相同名稱但參數清單不同。
- 執行時期多型性：透過動態方法分派實現，具體要執行的方法是在程式執行期間決定的。
🔗 理解關係
物件很少孤立存在。它們透過關係互動。視覺化這些連結是分析與設計的主要任務。
- 關聯：一種結構關係，其中一個類別的物件與另一個類別的物件連結。它代表「擁有」關係。
- 聚合：一種特殊形式的關聯，代表「整體-部分」關係，其中部分可獨立於整體存在。若整體被銷毀，部分仍存在。
- 組成： 一種更強的聚合形式。部分無法獨立於整體存在。若整體被破壞，部分也會隨之被破壞。
- 依賴： 一種關係，其中一個類別將另一個類別作為參數使用或作為結果返回。這是一種暫時性的「使用」關係。
- 多重性： 定義一個類別的實例與另一個類別的單一實例之間相關的數量（例如：一對多、多對多）。
📊 使用UML進行建模
統一建模語言（UML）是用於可視化系統設計的標準符號。雖然OOAD是過程，但UML是用來記錄該過程的語言。
類別圖
最常見的圖表類型。它透過顯示類別、屬性、方法和關係來呈現系統的靜態結構。這可作為開發人員實作系統時的指南圖。
用例圖
著重於從使用者角度出發的功能需求。它顯示參與者（使用者或外部系統）以及他們希望達成的用例（目標）。
順序圖
說明物件在特定情境下如何隨時間互動。它強調物件之間傳遞訊息的順序，以完成某項任務。
活動圖
類似於流程圖，這些圖表描述從一個活動到另一個活動的控制流程。它們對於模擬複雜商業規則的邏輯非常有用。
📋 快速參考表
使用此表格可快速複習核心術語。
| 術語 | 定義 | 類比 |
|---|---|---|
| 類別 | 物件的藍圖。 | 食譜 |
| 物件 | 類別的一個實例。 | 根據食譜烘烤出的蛋糕 |
| 封裝 | 限制對元件的存取。 | 藏有藥物的膠囊 |
| 繼承 | 從父類獲取屬性。 | 傳遞給子女的遺傳特徵 |
| 多態性 | 相同的介面，不同的行為。 | 用於不同裝置的遙控器 |
| 關聯 | 類別之間的關係。 | 一個人擁有一輛汽車 |
| 組合 | 強烈的所有權關係。 | 屬於身體的心臟 |
🛠️ 分析 vs. 設計
區分分析與設計階段，有助於在開發的正確階段使用適當的術語。
物件導向分析 (OOA)
著重於什麼系統應該做什麼。它識別問題領域並定義需求，而不考慮技術限制。
- 領域模型： 問題領域中概念與關係的呈現。
- 參與者： 與系統互動的實體。
- 使用案例： 提供可衡量價值給參與者的動作序列描述。
物件導向設計 (OOD)
著重於如何系統將如何執行。它將分析模型轉換為技術解決方案。
- 架構模式： 系統的基本結構（例如：分層式、MVC）。
- 設計模式： 一種可重複使用的軟體設計常見問題解決方案。
- 接口： 定義組件之間互動的合約。
🧩 設計模式概覽
設計模式是解決重複問題的經過驗證的方案。它們不是程式碼，而是解決問題的範本。
創建型模式
處理物件建立機制。範例包括單例模式（確保僅存在一個實例）和工廠模式（在不指定具體類別的情況下處理物件建立）。
結構型模式
處理類別與物件的組合。範例包括適配器模式（允許不相容的介面協同工作）和裝飾器模式（動態地為物件增加行為）。
行為型模式
處理物件之間的通訊。範例包括觀察者模式（通知物件狀態變更）和策略模式（定義一組演算法家族）。
🚀 為何術語至關重要
使用正確的術語不僅僅是學術練習。它能減少需求文件中的模糊性。當分析師指定「組合」而非「關聯」時，開發人員就能理解資料的生命週期限制。這種精確性可防止與記憶體管理及資料完整性相關的錯誤。
此外，強大的詞彙能促進合作。當團隊成員使用共同語言時，程式碼審查會更有效率，架構決策也能基於事實而非混淆進行討論。這讓新學生能閱讀現有的文件，理解遺留系統，而無需持續的指導。
📝 最後的想法
掌握物件導向分析與設計，始於用來描述它的詞彙。透過內化這些定義，學生能建立支援複雜問題解決的基礎。抽象、封裝、繼承與多型等概念不僅是流行語，更是建構穩健、可擴展軟體系統的工具。持續將這些術語應用於現實情境，將鞏固理解，並為學習者應對專業挑戰做好準備。
請記住，目標不是孤立地記憶定義，而是理解這些概念如何相互作用，形成一個協調一致的系統。隨著學習的進展，請不斷回顧這些核心術語，以確保你的設計始終清晰、邏輯嚴謹且可維護。