軟體系統很少是靜態的。它們會隨著數月甚至數年的時間不斷演進、擴展並適應變化的商業需求。然而，這種演進往往伴隨著一項隱藏成本，稱為技術債務。雖然技術債務常與快速修復或錯過期限有關，但它通常源自程式碼基礎架構本身。在物件導向程式設計中，類別是主要的構建單元。因此，類別設計中所嵌入的邏輯，直接影響整個系統的長期穩定性與可維護性。
當開發人員忽略其類別的結構完整性時，他們便會累積這筆債務的利息。每一個後續功能都變得更難加入，每一次錯誤修復都伴隨著更高的回歸風險，團隊的開發速度也將慢如爬行。本指南探討正確類別設計的機制，以及如何遵循特定的架構原則，在債務失控之前加以減輕。
🏗️ 理解基礎：內聚性與耦合度
評估類別健康狀況的兩個最重要指標是內聚性與耦合度。這些概念構成了穩定軟體架構的骨幹。忽略它們，等同於在沒有地基的情況下建造摩天大樓；結構或許能撐一陣子，但風（變化的需求）帶來的壓力最終將導致崩塌。
高內聚性：單一責任原則
內聚性指的是單一類別中各項責任之間的相關程度。具有高內聚性的類別專注於執行單一特定任務，並且執行得出色。這通常與單一責任原則同義。當一個類別處理多個無關的責任時，它將變得脆弱。
- 高內聚性： 一個專門根據地理位置與貨幣計算稅率的類別。
- 低內聚性： 一個負責計算稅額、處理付款、發送電子郵件收據，並記錄資料庫交易的類別。
當一個類別過於廣泛時，某個需求的變更會迫使整個類別進行修改。這會增加錯誤的潛在範圍。透過將這些責任分離到不同的類別中，變更的影響範圍將被限制。若電子郵件服務發生變更，稅額計算器仍不受影響。
低耦合：減少依賴
耦合度衡量軟體模組之間相互依賴的程度。低耦合表示一個模組的變更對另一個模組的影響極小或無需變更。高耦合會形成一個依賴網，修復一個問題時反而會破壞另一個問題。
考慮類別之間的關係。如果類別 A 在方法內部直接實例化類別 B，那麼類別 A 就與類別 B 緊密耦合。若類別 B 更改其建構函數的簽名，類別 A 也必須跟著更新。這會產生連鎖反應。
- 緊密耦合： 直接實例化、依賴具體實作、共享可變狀態。
- 鬆散耦合： 依賴注入、依賴介面、不可變的資料傳輸。
減少耦合不僅僅是為了程式碼的整潔；它更關係到組織的敏捷性。這讓不同團隊能在不互相干擾的情況下，各自開發不同的模組。
📐 SOLID 原則作為債務預防
SOLID 原則為類別設計提供了一條自然抵抗技術債務的路徑。這些不僅是理論上的指導原則，更是實際規則，規範了類別應如何互動與運作。
1. 單一責任原則（SRP）
一個類別應僅有一個變更的理由。如果你能想到兩個不同的原因，讓一個類別需要被修改，那麼它很可能違反了 SRP。此原則迫使開發人員將複雜問題拆解為更小、可管理的單元。
2. 開放/封閉原則（OCP）
軟體實體應對擴展開放，對修改封閉。這允許在不修改現有程式碼的情況下新增功能。這對於長期專案至關重要，即使功能不斷增加，核心邏輯也應保持穩定。
- 違反： 每當支援新的付款方式時，就新增一個
if/else區塊。 - 解決方案： 使用介面來處理付款方式，當新增實作時，以新增類別的方式加入。
3. 適用性替代原則（LSP）
父類別的物件應能被其子類別的物件取代，而不會破壞應用程式。這確保了繼承被正確使用。若子類別以出乎意料的方式改變父類別的行為，將會引入難以追蹤的隱性錯誤。
4. 介面隔離原則（ISP）
客戶端不應被迫依賴它們不需要的介面。大型、單一的介面是技術債務的來源。它迫使實作必須攜帶無法使用的方法，進而導致拋出 new NotImplementedException()或空方法。
5. 依賴反轉原則（DIP）
高階模組不應依賴低階模組。兩者都應依賴抽象。這使業務邏輯與基礎設施細節解耦。即使基礎設施變更（例如切換資料庫或 API），也不需重寫業務規則。
📊 結構可視化：類別圖的功用
類別圖不僅僅是文件化產物；它更是系統邏輯的藍圖。在長期專案中，程式碼經常與設計脫節。這種脫節是技術債務的主要指標。
維持精確的類別圖有助於團隊理解系統的複雜性。它能突顯出容易出錯的循環依賴與深層繼承樹。
圖中需監控的關鍵元素
| 視覺元素 | 其所代表的意義 | 債務風險 |
|---|---|---|
| 循環依賴 | 類別 A 依賴類別 B，而類別 B 又依賴類別 A。 | 高。會導致編譯問題與邏輯迴圈。 |
| 深層繼承樹 | 類別嵌套深度達 5 層或更多。 | 中等。難以預測子類別的行為。 |
| 上帝類別 | 一個包含過多程式碼行數與方法的類別。 | 高。單一失敗點與變更瓶頸。 |
| 義大利麵式連結 | 雜亂無章的跨模組連結。 | 高。難以維護且結構混亂。 |
定期將這些圖表與實際程式碼進行比對，可確保設計意圖與現實相符。若圖表顯示清晰的層次結構，但程式碼卻混亂不堪，團隊必須立即處理此差異。
🚫 早期識別反模式
某些設計模式在被誤用時會變成陷阱。早期識別這些反模式，可以避免日後數千小時的重構工作。
1. 神類
這是一個知道太多、做太多的事的類別。它作為系統的全局控制器。雖然一開始看似方便，但最終會成為瓶頸。沒有人敢碰它，因為破壞某部分的風險太高。解決方案是將它拆分成更小、更專注的類別。
2. 無血 Domain 模型
當類別僅包含 getter 和 setter，而沒有業務邏輯時，就會發生這種情況。所有邏輯都被推到服務類別中。這違反了封裝原則，使領域模型無法用來理解業務規則。邏輯應位於資料所在的位置。
3. 濕麵式程式碼
這指的是控制流程混亂的程式碼，通常是由於過度使用goto（在舊語言中）或過度嵌套的if/else語句。這使得執行流程難以追蹤。正確的類別設計規定，邏輯應封裝在具有明確輸入與輸出的方法中。
4. 功能嫉妒
當 Class A 中的方法過度存取 Class B 的屬性時，就會發生這種情況。這表示該方法應屬於 Class B。這能促進更好的內聚性，並減少 Class A 所需掌握的知識。
📉 隨時間推移的變更成本
良好類別設計最具說服力的論點之一，就是變更的經濟成本。在專案初期，變更成本很低。開發者可以輕易地將方法從一個類別移動到另一個類別。
然而，隨著系統成熟，這種成本會呈指數增長。不良設計會導致變更成本變得難以承受。這會導致「功能停滯」，即無法滿足新的業務需求，因為程式碼庫過於僵化。
影響變更成本的因素
- 可測試性：設計良好的類別更容易進行單元測試。設計不良的類別難以隔離，導致對重構缺乏信心。
- 可讀性：清晰的類別邊界讓新開發者更容易上手。結構模糊的程式碼需要更多時間才能理解。
- 可除錯性：當出現錯誤時，結構良好的系統能更快地進行根本原因分析。混亂的系統則需要追蹤多層依賴關係。
投入時間進行類別設計，是對未來效率的投資。這正是能適應市場的系統與逐漸過時的系統之間的差別。
🛠️ 針對遺留程式碼的重構策略
當專案已經背負技術債時，會發生什麼情況？答案不是重寫整個系統，而是策略性地進行重構。
1. 男孩 scout 法則
讓程式碼比你發現時更乾淨。每次你為了新增功能或修復錯誤而觸碰檔案時，都稍微改善一下結構。提取一個方法、重新命名變數，或將類別移動到更合適的位置。微小而持續的改進，能防止大規模技術債的累積。
2. 約束榕樹模式
這涉及逐步以新設計良好元件取代舊有的功能。你不會停止舊系統；而是在其周圍建立新系統，並逐步轉移流量。這使得可以逐類進行遷移，而無需冒著高風險的「大爆炸式」發佈。
3. 接口實現
首先為新設計定義接口。在這些接口後面實現舊代碼。這讓你可以逐步解耦系統。隨著時間推移，你可以在不更改調用代碼的情況下，將舊的實現替換為新的。
🤝 團隊動態與設計治理
程式碼是由團隊撰寫，而非個人。因此，類別設計必須是協作的成果。過度依賴單一「架構師」批准每一類，會導致瓶頸與不滿情緒。
結對編程
結對編程是一種確保設計品質的有效方式。兩個人即時審查類別結構，可以在提交前發現耦合問題與內聚性問題。這相當於一個持續的程式碼審查流程。
設計審查
在實作複雜邏輯之前，進行簡短的設計審查可節省大量時間。這並非微管理，而是確保與系統架構目標一致。這是一場關於為什麼一個類別被如此結構化的原因，而不僅僅是如何撰寫的方式。
文件
雖然程式碼是最好的文件，但註解仍有必要用來解釋類別結構的為什麼背後原因。類別圖形作為高階地圖，而內聯註解則說明具體決策。這些背景資訊對未來未參與原始設計的維護者至關重要。
🔮 維持架構健康
目標不是第一天就擁有完美設計，而是設計出能抵禦變化的系統。軟體架構是一門活的學問。隨著系統成長，類別設計的規則必須不斷重新檢視。
團隊應定期審查程式碼庫，尋找技術債的跡象。例如圈複雜度、耦合分數以及每類的程式碼行數等指標，可提供系統健康狀況的客觀數據。當這些指標急劇上升時，就是暫停功能開發、專注於重構的時機。
透過將類別設計視為專案成功的關鍵組成部分，團隊可確保其軟體始終是寶貴資產，而非負擔。隱藏在類別定義中的邏輯，正是決定專案未來走向的邏輯。對此邏輯給予適當關注，才能確保系統經得起時間考驗。