📚 物件導向分析與設計入門
在軟體架構的領域中，保持清晰與可擴展性至關重要。物件導向分析與設計（OOAD）提供了一個框架，將複雜系統分解為可管理且相互作用的元件。此方法的核心在於「繼承」這個機制，讓開發者能夠根據現有的類別建立新的類別，促進一種階層式結構，反映出現實世界中的關係。
當正確實施時，繼承能簡化開發流程，減少重複並確保核心邏輯在系統的不同部分保持一致。然而，若缺乏穩固的分析基礎而應用此概念，可能會導致結構僵化，難以修改。本指南探討了在OOAD中繼承的運作機制，分析其如何塑造程式碼結構並影響長期的可維護性。
🔍 繼承的核心概念
要理解繼承的實用性，首先必須了解類別之間的關係。在物件導向程式設計中，類別定義了物件的藍圖。繼承引入了父類與子類的關係，其中子類會繼承父類的屬性和行為。
🌳 類別層次結構
類別層次結構是一種類似樹狀的結構，其中類別根據彼此的關係進行排列。樹的頂端通常包含一個通用或抽象類別，通常稱為「超類別或基底類別」。位於其下的類別稱為「子類別或衍生類別.
- 超類別：定義一組相關物件共用的屬性和方法。
- 子類別：繼承自超類別，但也可定義獨特的屬性或覆寫現有的方法。
此層次結構允許邏輯上的分組。例如，一個通用的「車輛類別可能定義如「速度與燃料類型」等屬性。具體的車輛類別如「汽車 或 卡車 繼承這些特徵，同時增加像這樣的特定功能 車門數量.
🔗 IS-A 關係
繼承根本上代表一種 IS-A 關係。如果一個 汽車 類別繼承自一個 車輛 類別，那麼一輛汽車 IS-A 車輛。這種語義連結對於多態性至關重要，允許物件被視為其父類型的實例。
- 正確正例： 一隻鳥 IS-A 動物。（有效繼承）
- 錯誤正例： 一輛汽車 IS-A 引擎。（無效繼承 – 一輛汽車 HAS-A 引擎）
認識到這項區別可以防止結構性錯誤。當關係不是類型關係，而是擁有或關聯關係時，應使用組合（HAS-A）。
🏗️ 繼承模型的類型
不同的架構需求需要不同的繼承模式。了解可用的模型有助於為特定專案範圍選擇正確的方法。
1️⃣ 單一繼承
這是最簡單的形式，其中子類別僅繼承自一個超類別。它建立了一個清晰、線性的層次結構。
- 優點： 容易理解，複雜度最低，衝突風險降低。
- 缺點： 靈活性有限，可能需要多個基類來涵蓋所有需求。
2️⃣ 多層繼承
在這裡，一個類別繼承自另一個繼承自其他類別的類別。它建立了一個依賴鏈。
- 結構： 祖父母 → 父母 → 子女。
- 使用案例： 非常適合逐步專化，其中每一層都增加特定的限制。
3️⃣ 層次繼承
多個子類別繼承自單一的超類別。這在基於分類系統中很常見。
- 範例： 一個基底類別 Shape 擁有子類別 Circle, Square，以及 Triangle.
- 優勢： 將共用邏輯集中於基底類別中。
4️⃣ 多重繼承
一個類別繼承自多個超類別。雖然功能強大，但這會在方法解析方面引入顯著的複雜性。
- 複雜性： 需要仔細處理名稱衝突。
- 語言支援： 並非所有語言都原生支援此功能，這是因為 鑽石問題.
5️⃣ 混合繼承
兩種或更多種繼承類型的組合。此模型試圖在多重繼承的優勢與層次結構的清晰性之間取得平衡。
💡 架構上的戰略優勢
為什麼要花費精力設計繼承層次？其優勢遠超過簡單的程式碼重複。
♻️ 程式碼重用
主要驅動因素是重用性。透過在超類別中定義邏輯，該邏輯可被所有子類別使用而無需重寫。這能減少程式碼行數，並最小化錯誤的潛在範圍。
🛠️ 可維護性
當需要修改共用行為時，更新超類別會將變更傳播到所有子類別。這種集中化使維護變得可預測。
🔒 封裝與抽象
繼承透過隱藏父類別的實作細節來支援抽象。子類別與父類別的公開介面互動，確保內部資料受到保護。
🧩 多型性的基礎
多型性依賴於繼承。它允許單一介面代表不同的底層形式（資料類型）。這對於靈活的系統設計至關重要，使不同物件能以統一方式處理。
⚠️ 風險與反模式
雖然繼承功能強大，但濫用會降低系統品質。了解這些陷阱與理解其優點同等重要。
🚫 過度繼承
建立過深的層次結構（超過3-4層）會使系統變得脆弱。基類的變更可能在整個樹狀結構中產生未預期的連鎖反應。
🔗 緊密耦合
子類別會與其父類別緊密耦合。即使公開介面保持不變，若父類別改變其內部實作，子類別仍可能失效。
🐍 鑽石問題
在多重繼承中，若一個類別繼承自兩個皆繼承自共同祖先的類別，則會產生歧義，無法確定應呼叫哪個祖先的方法。解決此問題需要特定的語言特性或設計模式。
🧱 易碎的基類
過於複雜或頻繁變動的基類會成為瓶頸。子類別依賴於此基類的穩定性。若基類發生變動，整個層次結構都會受影響。
📊 繼承 vs. 組合
在物件導向分析與設計中，選擇繼承或組合是一個關鍵決策。組合通常因其靈活性而被優先考慮。
| 功能 | 繼承 | 組合 |
|---|---|---|
| 關係 | 是-一個 | 有-一個 |
| 彈性 | 低（編譯時期靜態） | 高（執行時期動態） |
| 封裝 | 較低（受保護成員經常外露） | 較高（內部細節隱藏） |
| 可重用性 | 行為高，狀態低 | 狀態與行為皆高 |
| 複雜度 | 隨著深度增加 | 隨著物件數量增加 |
原則：當關係為嚴格時，使用繼承IS-A當關係為HAS-A或當行為需要動態變更時。
🛠️ 實作原則
遵循既定原則可確保繼承結構保持穩健。
1. 違背替代原則（LSP）
子類型必須可替代其基類型。若一程式設計為使用Vehicle物件，以Car物件取代時不應破壞系統。此原則可防止子類別違反超類別的合約。
2. 接口隔離
許多小型、特定的介面，優於一個大型、通用的介面。子類別不應被迫實作其不需要的方法。這可減少冗餘與混淆。
3. 優先選擇組合而非繼承
如前所述，深層的繼承結構通常是一種程式碼壞味道。若一類別需要來自多個來源的行為，應考慮組合物件，而非從多個類別繼承。
4. 抽象基類
使用抽象類別來定義子類別必須遵守的合約。這可確保整個繼承層級的一致性，而無需為每種可能情境實作具體邏輯。
5. 避免公開受保護成員
盡量減少在超類別中使用受保護成員。這迫使子類別透過明確定義的公開方法進行互動，以維護封裝性。
📝 實用分析步驟
應用此理論需要在分析和設計階段採取結構化的方法。
- 識別實體： 列出問題領域中的名詞。哪些是相關的？
- 確定關係： 它們是 IS-A 還是 HAS-A？繪製圖表以進行視覺化。
- 定義共通性： 哪些屬性和方法是真正共用的？
- 優化層次結構： 限制層次深度。問問看子類是否必須是基類的直接子類，還是需要一個中間層？
- 檢視耦合度： 檢查基類的變更是否會產生過大的波及效應。
🚀 携手結構向前邁進
有效的程式碼結構是永續軟體的骨幹。當理解並有紀律地應用繼承時，它能提供強大的工具來組織邏輯。只要基礎關係保持穩固，系統就能隨著需求變更而演進。
開發人員必須保持警覺，避免在不適合的情況下強行使用繼承。目標不是最大化繼承的使用，而是最小化複雜性，同時最大化清晰度。透過平衡繼承與組合，並遵循設計原則，架構師可以建立穩健、可擴展且長期更易維護的系統。
最終，結構的選擇決定了軟體的壽命。經過仔細考量的層次結構能減少技術負債，而隨意的結構則會產生負債。在設計階段進行仔細分析，能在開發和維護階段帶來回報。
