物件導向分析與設計（OOAD）仍然是現代軟體架構的骨幹。它提供了一種結構化的系統建模方法，其中資料與行為被封裝於物件之中。然而，建立穩健系統的道路往往充滿了細微的架構決策，這些決策會隨時間逐漸退化。開發人員經常陷入看似初期高效，但後期會造成重大技術負債的模式。
本指南探討會損害設計完整性的具體陷阱。透過理解這些陷阱的症狀與成因，團隊能夠維持彈性並降低維護成本。我們將檢視導致脆弱程式碼庫的結構性弱點，並探討如何設計能長久維持的系統。
🧬 繼承陷阱：過深的層級結構
OOAD 中最普遍的問題之一是繼承的濫用。雖然繼承允許程式碼重用與多型，但它會產生僵化的依賴鏈。當開發人員過度依賴類別層級結構時，往往會形成過深的類別樹狀結構，使得導航或修改變得困難。
為什麼繼承會成為問題
- 脆弱的基底類別： 基底類別的任何變更都可能破壞所有衍生類別的功能。這被稱為脆弱基底類別問題。
- 隱藏的依賴： 衍生類別經常依賴其父類別的內部實作細節，而這些細節本應保持私有。
- 彈性受限： 繼承是一種編譯時期的關係。它是靜態的，無法在執行時期動態改變行為。
辨識症狀
如果你發現自己只是為了共享程式碼而建立類別，卻沒有明確的「是一種」關係，那很可能是在濫用繼承。請留意：
- 大量程式碼專注於覆寫方法的類別。
- 複雜的邏輯分散在父類別與子類別之間。
- 方法會拋出例外，因為它們不適用於特定的子類別。
建議：優先使用組合而非繼承。建立包含其他物件的物件。這允許行為在不改變類別層級結構的情況下動態切換。
🏛️ 神物件反模式
「神物件」是一種知道太多或做太多事情的類別。它通常作為應用程式的中央樞紐，處理從資料取得、商業邏輯到UI繪製等所有事項。雖然這可能簡化初期開發，卻會造成測試與維護的巨大瓶頸。
神物件的特徵
| 特徵 | 對系統的影響 |
|---|---|
| 大小 | 通常超過數百甚至數千行程式碼。 |
| 耦合度 | 幾乎依賴系統中所有其他類別。 |
| 責任 | 混合資料存取、邏輯與呈現。 |
| 可維護性 | 修改時具有很高的回歸風險。 |
單體類的代價
當單一類別管理整個應用程式的狀態時，就無法隔離變更。如果出現錯誤，很難追查來源。此外，多名開發人員同時在相同檔案上工作時，會在版本控制中不斷遇到合併衝突。
建議： 應用單一責任原則（SRP）。確保每個類別僅有一個變更的理由。將大型類別拆分成更小、更專注的單元。使用依賴注入來提供必要的服務，而不是在內部創建它們。
🔗 緊密耦合與依賴管理
耦合指的是軟體模組之間相互依賴的程度。高耦合表示一個模組的變更會導致其他模組也必須變更。在物件導向分析與設計（OOAD）中，這通常表現為類別直接創建其依賴項的實例。
直接實例化問題
當一個類別使用new來建立依賴時，會將自身綁定到特定的具體實作。這會阻止使用替代實作，例如測試用的模擬物件，或針對不同環境使用的不同策略。
- 測試困難：由於無法輕易地模擬依賴，單元測試會變成整合測試。
- 重構成本： 更換底層技術需要在整個程式碼庫中進行大規模變更。
- 可重用性： 類別無法輕易地移至另一個專案，而不會一併攜帶其依賴。
鬆散耦合的解決方案
為減輕此問題，應依賴介面或抽象類別。定義類別需要什麼，而非如何取得它。這使得依賴可從外部注入。這種方法通常稱為依賴注入。
- 使用介面來定義合約。
- 透過建構函式或設定器傳入依賴來建構物件。
- 將實作細節隱藏在公開合約之後。
📜 介面分割與肥大介面
介面的用途在於定義合約。然而，當介面過於龐大時，反而會成為負擔。這通常被稱為違反介面分割原則。客戶端不應被迫依賴它們不需要的方法。
肥大介面問題
想像一個擁有二十個方法的介面。實作此介面的類別必須提供全部二十個方法，即使它只使用其中兩個。這會導致：
- 空實作： 會拋出
NotImplementedException或者什麼都不做。 - 混淆： 開發人員無法判斷哪些方法與其特定使用情境相關。
- 編譯錯誤： 如果介面變更，所有實作都必須更新，即使變更對它們而言毫無關聯。
介面的最佳實務
保持介面小巧且專注。將相關功能分組到獨立的介面中。這讓類別只需實作所需的內容。同時也能讓系統更具模組化且更易於理解。
📊 資料結構 vs. 物件
OOAD 中常見的混淆是將物件僅視為純資料容器。雖然物件封裝資料，但也應封裝行為。將物件視為資料結構會導致「貧血領域模型」，其中物件擁有公開欄位卻無任何邏輯。
貧血模型的陷阱
當資料與邏輯分離時，你會得到包含所有商業規則的 Service 類別。這違反了封裝原則。資料會因物件內部缺乏不變性驗證而容易陷入不一致狀態。
封裝的最佳實務
- 將欄位設為私有，並透過方法暴露狀態。
- 確保方法以維持物件有效性的方式修改狀態。
- 將屬於資料的邏輯移入物件本身。
透過將資料與行為結合，可減少錯誤的發生範圍。物件本身便成為維護自身完整性的守護者。
🎯 里氏替換原則（LSP）
LSP 指出，超類別的物件應能被其子類別的物件取代，而不會破壞應用程式。違反此原則會導致多型使用時出現不可預測的行為。
子型別違反
考慮一個從矩形類別繼承的正方形類別。若設定寬度，高度必須保持不變；若設定高度，寬度也必須保持不變。正方形無法滿足此約束。因此，在此情境下，正方形並非矩形的有效子型別。
這種語義上的不匹配會破壞使用該物件的程式碼的預期。迫使使用者在使用前必須檢查具體類型，這違背了多型的初衷。
確保符合 LSP
- 確保子類別不會強化前置條件。
- 確保子類別不會弱化後置條件。
- 確保子類別不會改變超類別的不變性。
⚖️ 單一責任原則（SRP）的細節
SRP 常被誤解為「一個類別，一個工作」。實際上，它的意思是「一個變更的原因」。一個類別可能處理多項任務，但如果這些任務由不同利益相關者或變動的需求驅動，就應該分離。
識別責任
問問自己：「是什麼導致這個類別需要變更？」如果答案是多個不同的因素，則此類別具有多重責任。常見的罪魁禍首包括：
- 資料庫存取邏輯與商業規則混雜。
- 格式化邏輯與計算邏輯混合。
- 記錄邏輯與核心功能混合。
分離這些關注點允許團隊並行工作。一個團隊可以更新資料層而不影響計算層。
🔄 迭代器陷阱
迭代器允許遍歷集合。然而，若未正確管理，自定義迭代器可能引入複雜性。透過自定義迭代器暴露集合的內部結構，會使客戶端與該特定結構緊密耦合。
何時使用標準迭代器
除非你有特定的自定義遍歷需求，否則應依賴標準集合迭代器。它們經過充分測試且可預測。為每種集合類型創建新的迭代器會增加不必要的重複程式碼，並帶來潛在的錯誤。
🔒 封裝與可見性
封裝是隱藏內部狀態的原則。然而，過度封裝會阻礙開發，而封裝不足則會使系統暴露於錯誤之中。找到平衡點至關重要。
可見性修飾符
- 公開： 慎用。僅暴露合約所必需的部分。
- 受保護： 用於繼承，但須注意其引入的脆弱性。
- 私有： 默認使用此設定。隱藏實現細節。
不要僅因方便就將方法設為公開。若方法不在公開合約中，應保持私有。這可減少錯誤的暴露面積。
📈 對技術債務的影響
上述討論的每個設計陷阱都會導致技術債務。技術債務是指因選擇當前容易的解決方案，而非耗時更長但更好的方法，而產生的額外返工的隱含成本。
長期後果
- 開發速度變慢： 更多時間花在修復錯誤上，而非新增功能。
- 更高的入職成本： 新開發者難以理解複雜且緊密耦合的系統。
- 重構風險： 擔心破壞現有功能，導致無法進行必要的改進。
在清晰設計上投入時間，能在軟體的整個生命周期中帶來回報。它能降低團隊的認知負擔，並使系統更具適應變化的能力。
🛡️ 設計穩定性的總結
建立穩健的軟體需要保持警覺。本指南中列出的陷阱之所以常見，是因為它們提供了短期便利。然而，長期代價高昂。透過優先考慮鬆散耦合、高內聚性以及遵守既定原則，團隊才能打造出持久的系統。
請記住，設計不是一次性的活動。它是一個迭代的過程。持續根據這些標準審視你的架構。必要時進行重構。不要讓「能運作的程式碼」思維掩蓋了「可維護的程式碼」目標。
📝 OOAD 的重點摘要
- 避免過深的繼承：使用組合來實現重用。
- 防止上帝對象：讓類別專注於單一責任。
- 管理依賴關係：注入依賴關係，而不是自行建立。
- 簡化介面：保持它們小巧且具體。
- 保護狀態：封裝資料並強制執行不變式。
- 尊重 LSP：確保子類別能無縫取代父類別。
採用這些實務需要紀律。寫一段快速腳本比設計一個系統容易得多。但原型與產品之間的差別，往往取決於底層設計的品質。保持對結構的覺察，你的軟體將能可靠地服務多年。