物件導向設計中的五個常見錯誤及其避免方法

物件導向設計（OOD）是可維護軟體架構的基石。它提供了一種結構化的方法來在程式碼中模擬現實世界的實體，促進重用性和清晰度。然而，若錯誤地應用這些原則，可能會導致脆弱的系統，難以擴展或除錯。許多開發者在設計類別與互動時，會落入可預測的陷阱。

本指南將檢視典型 OOD 實作中發現的五個關鍵錯誤。我們將探討這些錯誤背後的機制，並提供具體的修正策略。透過理解其根本原因，您便能建構出經得起時間考驗的系統。

1. 過度使用繼承層次結構 🌳

物件導向程式設計中最普遍的問題之一，就是過度依賴深層的繼承樹。雖然繼承能透過多型實現程式碼重用，但過度使用會導致父類與子類之間產生緊密耦合。當基底類別變更時，所有衍生類別都可能意外地失效。

問題：脆弱的基底類別

• 隱藏的相依性： 子類別經常依賴父類別的實作細節，而不僅僅是其介面。
• 違反李氏替換原則： 子類別在取代父類別時，可能無法正確運作，進而導致執行時期錯誤。
• 複雜度增加： 新增功能時，通常需要修改基底類別，進而影響所有現有的子類別。

解決方案：優先選擇組合而非繼承

不要建立「是…的一種」的關係，而應偏好「擁有…」的關係。透過結合小型、專注的物件來達成功能。這種方法能降低耦合度，並允許在執行時期動態改變行為。

程式碼結構比較

方法	彈性	可維護性	建議使用情境
深層繼承	低	低	僅適用於真正的數學層次結構（例如：形狀 → 圓形）
組合	高	高	大多數的商業邏輯與功能實作

在設計系統時，請問自己：子類別是否在所有情境下都真正代表父類別？如果答案是否定的，請考慮使用介面或組合來連結行為。

2. 違反封裝性 🚫📦

封裝是隱藏內部狀態，並要求透過定義好的方法進行互動的原則。然而，開發者經常公開欄位，或提供無邏輯的簡單存取器與設定器。這使得類別變成了資料結構，而非具有行為的物件。

為何公開狀態是危險的

• 失去控制：外部程式碼可以立即將物件狀態修改為無效狀態。
• 不變式被破壞：本應始終成立的限制條件（例如年齡不能為負數）被忽略。
• 重構困難：更改資料儲存方式，需要更新所有直接存取該欄位的檔案。

資料隱藏的最佳實務

1. 將欄位設為私有：確保所有成員變數無法從類別外部存取。
2. 受控存取：使用公開方法來讀取或修改資料。
3. 驗證邏輯：在設定方法中插入驗證邏輯，以維持資料完整性。
4. 不可變性：在可能的情況下，建立物件後使其不可變，以完全防止狀態變更。

考慮一個銀行帳戶類別。如果餘額是公開的，任何程式碼都可以將其設為零或負數。如果餘額是私有的，該類別可以在存款方法中強制執行「不得透支」等規則。

3. 建立神類（大型類別） 🏛️

神類是一種知道太多且做太多事情的類別。這些類別經常同時處理資料庫連接、使用者介面邏輯、商業規則和檔案輸入/輸出。它們會變成龐大且難以閱讀的檔案，修改起來令人恐懼。

神類的徵兆

• 程式碼行數過多： 這個類別超過 500 行，且缺乏明確的區分。
• 許多責任： 它執行不相關的任務（例如發送電子郵件和計算稅款）。
• 高扇出： 它依賴於許多其他類別。

透過單一責任原則解決

單一責任原則指出，一個類別應只有一個變更的理由。將神類拆分成更小、更專注的類別。

重構策略

1. 識別內聚性：將邏輯上相互配合的方法歸為一組。
2. 提取類別：將相關的方法移至新的類別中。
3. 引入介面：為新類別定義合約，以確保解耦。
4. 委派：原始類別應將任務委派給新的專用類別。

例如，將一個ReportGenerator類別與一個DatabaseConnection類別分離。報表產生器應請求資料，而非自行管理連接。

4. 模組之間的緊密耦合 🔗

耦合指的是軟體模組之間相互依賴的程度。高耦合表示一個模組的變更會迫使另一個模組也進行變更。這會產生多米諾效應，導致在一個區域修復錯誤時，會破壞另一個區域的功能。

應避免的耦合類型

• 直接實例化：在類別內部使用new來建立依賴關係，這會使測試變得困難並產生硬連結。
• 具體依賴：依賴於具體實作，而非抽象層。
• 全域狀態：使用全域變數來共享資料會產生隱藏的依賴關係。

鬆散耦合的策略

鬆散耦合允許模組獨立運作，這對於可擴展性和測試至關重要。

• 依賴注入：透過建構函式或方法將依賴項傳入類別，而非在內部建立它們。
• 介面隔離： 依賴符合客戶需求的介面。
• 事件驅動架構： 使用事件來通知其他系統變更，而無需直接呼叫。

透過注入依賴性，你可以輕鬆替換實作。例如，你可以在測試時使用模擬資料庫，而生產系統使用真實資料庫，且無需更改核心邏輯。

5. 忽略內聚性 🧩

內聚性衡量單一模組中責任之間的相關程度。低內聚性表示一個類別包含彼此關聯性極低的方法。這使得類別難以理解與重用。

內聚性的層級

類型	描述	狀態
偶然內聚性	方法隨意分組。	不良
邏輯內聚性	方法依類型分組（例如，所有「列印」方法）。	可接受
功能內聚性	方法共同貢獻於單一明確的任務。	最佳

提升內聚性

目標是功能內聚性。類別中的每個方法都應貢獻於單一明確的目的。

• 檢視方法名稱： 如果方法名稱不符合類別的用途，則應移動它。
• 拆分大型類別： 如果一個類別處理多個不同的任務，則應將其拆分。
• 專注於領域： 將類別結構與業務領域概念對齊。

高內聚性可帶來更易於測試與除錯的程式碼。若發生錯誤，你便能精確知道應檢查哪個類別。

最佳實務總結 ✅

避免這些錯誤需要紀律與持續的重構。以下是一份快速檢查清單，供您進行設計審查時使用。

• 檢查繼承：這是否為「是一種」關係，還是應該使用組合？
• 驗證封裝：所有資料欄位都是私有的嗎？
• 分析大小：這個類別是否承擔了太多功能？
• 檢視依賴關係：這個類別是否能在沒有特定依賴的情況下運行？
• 衡量內聚性：所有方法是否都服務於一個明確的目標？

關於系統穩定性的最後想法 🛡️

優秀的設計是看不見的。當你正確地實施這些原則時，程式碼會自然流暢地運作。你將花更少時間修復錯誤，更多時間創造價值。初期花費精力正確地組織類別，在維護階段會帶來顯著回報。優先考慮清晰度與彈性，而非快速捷徑。

請記住，設計是一個迭代的過程。隨著需求的演變，定期檢視你的架構。對上述錯誤的徵兆保持警覺。透過維持高標準，確保你的軟體始終穩健且具備適應性。