建立穩健的軟體不僅僅是撰寫能編譯的程式碼。它需要扎實的基礎，建立在物件導向分析與設計（OOAD）。當應用程式的初始結構有缺陷時，隨著專案規模擴大，修正成本會呈指數級增長。開發人員經常發現自己不斷重複重構相同的模組，因為核心設計決策是在缺乏對長期可維護性明確理解的情況下做出的。
本指南探討了在分析與設計階段最常見的陷阱。我們將識別具體的反模式，解釋它們發生的原因，並提供可執行的策略來修正它們。透過早期解決這些問題，您可以確保您的架構保持彈性與韌性。
1. 緊密耦合的陷阱 🕸️
緊密耦合發生在類別過度依賴其他類別的內部實作細節時。它們不透過抽象介面互動，而是過度了解彼此的具體類型與方法。這會造成一個脆弱的系統，其中改變一個組件會迫使許多其他組件也跟著改變。
為何會發生
- 直接實例化：在其他類別中直接建立具體類別的實例，而不是使用相依性注入。
- 過度知識：類別之間傳遞複雜的資料結構或內部狀態物件。
- 缺乏抽象：未能定義介面或抽象基類來解耦相依性。
技術上的影響
當耦合度高時，系統會變得僵硬。你無法獨立測試特定模組，因為它需要完整的相依性鏈路運作。重構變得風險高，因為某個區域的變更會產生無法預測的連鎖反應。單元測試難以撰寫，導致過度依賴緩慢的整合測試。
解決方案
應用相依性逆轉原則。依賴抽象，而非具體實作。使用介面來定義合約。實作相依性注入，以提供相依性，而非在內部建立。這讓您能在不修改客戶端程式碼的情況下更換實作。
2. 「神類」反模式 🏛️
神類是一種過於龐大且承擔太多不同任務的類別。它經常同時處理資料持久化、商業邏輯、使用者介面更新與檔案 I/O 等邏輯。這違反了單一責任的核心原則。
警示訊號
- 這個類別擁有數百個方法。
- 它需要很長時間才能載入或實例化。
- 任何商業邏輯的變更都必須修改這一個檔案。
- 程式碼審查者難以理解變更的範圍。
解決方案
透過將關注點提取到更小、更緊密的類別中，來重構神類。每個類別都應只有一個變更的理由。例如，將資料存取邏輯與商業邏輯分離。將與顯示相關的邏輯移至控制器或檢視層。這能提升可讀性，並讓程式碼庫更易於導航。
3. 混用繼承與組合 🧬
繼承是一種強大的工具，但在分析和設計中經常被過度使用。深層的繼承層次結構可能導致「脆弱基類」問題。當父類改變時，所有子類都會受到影響，即使它們並不需要此改變。此外，繼承經常被用來實現行為，而非用來建模「是一種」的關係。
問題
開發人員經常建立像這樣的類別員工, 經理，以及董事於一個深層的樹狀結構中。如果員工類別更改其薪資計算邏輯，則經理類別可能會意外地失效。這種層級之間的緊密耦合限制了彈性。
解決方案
採用組合優於繼承。而不是繼承行為，應組合提供該行為的物件。使用介面來共享合約，並將功能委派給輔助物件。這使得您可以在不改變類別層次結構的情況下於執行時期變更行為。同時也促進了重用性，因為相同的輔助物件可被應用於不同且無關的類別之間。
4. 忽略SOLID原則 🛑
SOLID原則為可維護的物件導向設計提供了路徑圖。在分析階段忽略這些原則，通常會導致技術負債不斷累積。每個字母代表一個特定的指導原則，遵循它們能降低複雜度。
原則解析
- S – 單一責任原則： 一個類別應僅有一個變更的理由。將責任分散到多個類別中。
- O – 開放/封閉原則： 機體應對擴展開放，但對修改封閉。使用介面來允許新增功能，而無需觸碰現有的程式碼。
- L – 違背取代原則： 子型別必須能取代其基類型。如果子類改變了父類預期的行為，則層次結構存在缺陷。
- I – 介面隔離原則： 客戶端不應被迫依賴它們不需要的介面。應將大型介面拆分成較小且具體的介面。
- D – 依賴反轉原則： 高階模組不應依賴低階模組。兩者都應依賴抽象。
5. 過早優化與過度設計 🚀
相反地，有些設計師花費過多時間預期未來可能永遠不會實現的需求。這導致過度設計。在應用程式甚至尚未處理任何實際交易之前，你可能會建立複雜的工廠模式、抽象工廠，或複雜的快取層。
後果
複雜度增加，但價值並未提升。新開發人員難以理解程式碼。除錯變得更困難，因為邏輯分散在許多間接層中。專案進度變慢，因為初始實作過於僵化。
解決方案
遵循 YAGNI（你不會需要它）原則。僅為當前功能所需而建構。若後續需要某種模式，可在重構時引入。在效能或可擴展性瓶頸經由指標證明前，保持設計簡單。
6. 忽視領域建模 🗺️
OOAD中最關鍵的錯誤之一，是將程式碼與業務領域分離。開發人員經常將資料庫結構直接映射到程式碼結構中，導致貧弱的領域模型。這意味著類別僅儲存資料（getter 和 setter），而業務邏輯則位於獨立的服務類別中。
問題
這種做法違反了封裝原則。業務規則分散在各個服務中，難以確保不變性。領域邏輯變得不可見，程式碼變成資料傳輸物件的集合，而非業務現實的呈現。
解決方案
專注於 普遍語言。確保你的類別名稱與方法符合業務相關方使用的術語。將業務邏輯嵌入領域物件中。一個 Order物件應知道如何計算其總價，而非依賴外部服務。這使程式碼具備自文件化特性，並更容易根據業務規則進行驗證。
設計審查清單 📋
為確保設計穩健，請在程式碼審查與架構規劃期間使用以下清單。
| 檢查 | 是/否 | 備註 |
|---|---|---|
| 類別是否小而專注？ | ||
| 類別是否依賴介面？ | ||
| 繼承是否僅限於真正的「是」關係？ | ||
| 業務邏輯是否位於領域物件中？ | ||
| 依賴是否透過注入而非建立？ | ||
| 設計是否容易獨立測試？ |
7. 不足的錯誤處理與狀態管理 ⚠️
為順利流程設計很常見，但忽略錯誤狀態會導致系統不穩定。物件通常假設傳入的資料始終有效。當出現邊界情況時，這會導致空指針異常或狀態不一致。
最佳實務
- 在邊界處進行驗證：在資料進入系統後立即檢查，處理前進行驗證。
- 使用不可變性：在可能的情況下，使物件不可變。這可防止處理過程中狀態意外變更。
- 快速失敗：如果前置條件未滿足，立即拋出異常，而不是讓系統在無效狀態下繼續運作。
- 選項類型：使用語言功能如 Optional 類型，明確處理值缺失的情況，而非在各處依賴空值檢查。
8. 文件缺口 📝
程式碼是主要文件，但不夠。若沒有清楚記錄設計決策，未來的維護者將難以理解為何某些結構存在。這常導致意外的重構，破壞原本的架構設計。
應記錄的內容
- 架構決策：記錄為何選擇某種模式而非其他模式。
- 類別責任：明確說明一個類別做什麼，以及不做什麼。
- 互動：使用順序圖來展示物件在複雜工作流程中如何互動。
- 限制條件：記錄任何影響設計的效能或記憶體限制。
9. 重構成本與預防成本的比較 💰
將設計修正推遲到後期階段很有誘惑力。然而，隨著程式碼庫的擴大，修正設計錯誤的成本會增加。在分析階段發現的錯誤修正成本極低。在部署後才發現的錯誤則需要資料庫遷移、API 更新以及廣泛的回歸測試。
戰略性重構
若你接手一個遺留系統，不要試圖一次重寫全部。使用 童軍守則：永遠讓程式碼比你發現時更乾淨。當為某個功能觸及模組時，稍微重構設計以改善它。這種逐步方式可降低風險，同時穩步提升品質。
10. 分析與設計工具 🛠️
雖然軟體工具各異，但原則始終不變。在撰寫程式碼前，使用建模工具來視覺化類別圖。建立原型以驗證設計假設。運用靜態分析工具自動檢測耦合度與複雜度指標。這些工具可協助識別設計原則的違規，無需完全依賴人工審查。
關於永續設計的最後想法 🌱
物件導向分析與設計是一個持續的過程，而非一次性任務。隨著需求的演變，你的設計必須能夠適應。目標不是在第一天就創造出完美的系統，而是建立一個能夠順利演進的系統。透過避免這些常見錯誤並遵循既定原則，你將奠定支持長期發展的基礎。
專注於簡潔性、清晰度與可維護性。當有疑問時，請問自己六個月後要修改這個設計會有多容易。如果答案是困難的，就重新考慮你的方法。一個設計良好的系統，是讓變更輕鬆的系統，而不是無法變更的系統。
