作為初級工程師開始一個新的軟體專案可能會讓人感到壓力山大。為了快速交付程式碼的壓力，常常導致跳過關鍵的規劃階段。然而，穩定應用程式與脆弱程式碼庫之間的差異，往往就在分析與設計階段。物件導向分析與設計（OOAD）提供了一種結構化的方法，用以理解需求並轉化為穩健的架構。
許多開發者直接跳入實作階段，結果卻不斷需要重構，或苦於理不清的複雜依賴關係。本指南作為實用的參考工具，明確列出在撰寫第一行邏輯之前，確保設計穩固所需的必要步驟。遵循此清單，你將建立一個能支援未來擴展與維護的堅實基礎。
🧠 第一階段：理解問題空間
在定義類別或方法之前，你必須清楚系統應當做什麼。分析的重點在於發現，而非實作。若未明確界定問題的範圍，解決方案將不可避免地偏離方向。
- 識別參與者：誰會與這個系統互動？是人類使用者、外部 API，還是背景排程器？列出所有觸發動作的實體。
- 定義目標：主要目標是什麼？是資料處理、使用者管理，還是即時監控？請清楚地寫下來。
- 界定範圍：系統包含哪些內容，更重要的是，哪些內容被排除在外？範圍蔓延常發生於初始邊界定義過於模糊時。
若對上下文缺乏清晰的認識，你將有風險打造出與使用者實際需求不符的功能。請使用簡單的圖示來呈現你的軟體將運作的環境。
📋 第二階段：功能需求與使用案例
功能需求描述系統必須展現的特定行為。在物件導向的脈絡中，這些行為直接對應到類別中的方法與動作。
1. 使用案例分析
使用案例描述一連串能為參與者產生可觀察且具價值結果的動作。在檢視需求時，請提出以下問題：
- 觸發條件是什麼？哪個事件啟動了這個流程？
- 主要流程是什麼？所有事情都順利進行的標準路徑。
- 替代流程是什麼？系統如何處理錯誤、取消或意外輸入？
- 後置條件是什麼？動作完成後，系統必須處於何種狀態？
2. 使用者故事
雖然使用案例較為正式，但使用者故事提供了一種輕量級的替代方式來捕捉需求。標準格式有助於保持焦點：
作為[角色]，我想要[功能]，以便[效益]。
確保每個故事都有驗收標準。這些標準明確定義了需求達成的時機。它們將成為未來開發的測試案例。
🏗️ 第三階段：概念模型建立
當需求明確後，你便開始將其轉化為物件。這正是物件導向分析的優勢所在。你需在問題領域中尋找名詞與動詞。
1. 识别類別與物件
大聲朗讀您的需求文件。標示出名詞。這些很可能是類別或實體的候選者。然而，並非每個名詞都會變成類別。請加以區分：
- 實體： 在系統中持續存在的事物（例如，使用者, 訂單).
- 介面： 促進通訊的事物（例如，通知服務).
- 值物件： 由其屬性定義而非身份的事物（例如，金額, 地址).
請小心不要創建過於細小或過於龐大的類別。一個類別應該只有一個變更的理由。如果一個類別同時處理資料庫連接、使用者驗證和電子郵件發送，那就太大了。
2. 定義責任
每個物件都必須知道某件事或執行某件事。這個概念稱為責任驅動設計。針對每個候選類別，定義：
- 它持有什麼資訊？（屬性/屬性）
- 它執行哪些操作？（方法/函數）
- 它對其他物件了解什麼？（關係）
使用「GRASP 模式作為心理導向。這些原則有助於正確分配責任。例如，資訊專家 模式建議將責任分配給擁有完成該責任所需資訊的類別。
🔗 第四階段：結構設計與關係
物件並非孤立存在。它們會相互作用。你的設計必須定義這些物件之間的關係。結構決定了程式碼的複雜度。
1. 關係類型
理解這些基本關係之間的差異：
- 關聯： 物件之間的連結，其中彼此知道對方的存在（例如，一名學生 登記修讀一門課程).
- 聚合： 一種「整體-部分」關係，其中部分可以獨立存在（例如，一個系所 擁有教授，但教授的存在不依賴於系所）。
- 組合： 一種更強的「整體-部分」關係，其中部分無法在沒有整體的情況下存在（例如，一棟房屋 擁有房間；如果房屋被摧毀，房間也隨之消失）。
- 繼承： 一種關係，其中一個類別是另一個類別的特殊化版本（例如，卡車 是一種車輛).
2. 管理複雜性
複雜的關係會導致複雜的程式碼。應追求簡潔。如果一個類別需要了解另外五個類別才能執行簡單的任務，則應考慮引入中介者或重構邏輯。
使用類別圖來視覺化這些關係。即使你沒有使用正式的建模工具，僅在紙上繪製方框和箭頭，也有助於識別循環依賴或過於深層的繼承樹。
⚙️ 第五階段：行為設計
結構是靜態的；行為是動態的。物件如何協作以達成目標？此階段專注於資料與控制的流動。
1. 序列圖
序列圖顯示物件如何隨時間互動。它將物件置於水平軸上，時間則置於垂直軸上。繪製時應注意：
- 從外部觸發事件（使用者或系統）開始。
- 追蹤訊息從一個物件傳遞到另一個物件的流程。
- 識別資料何時被建立、修改或銷毀。
- 確保迴圈與條件都清楚標示。
此練習能揭露隱藏的依賴關係。你可能會發現物件 A 正在呼叫物件 B，而物件 B 又呼叫物件 C，僅為了取得一個簡單的字串。這就是優化目標。
2. 狀態管理
有些物件在其生命週期中會有顯著的狀態變化。例如一個文件可能處於以下狀態：草稿, 審核中, 已發佈，或已存檔.
- 定義每個物件的有效狀態。
- 定義導致狀態轉移的事件。
- 確保無效的轉移被阻止。例如一個已發佈 文件不應直接編輯。
忽略狀態邏輯通常會導致資料處於不一致狀態的錯誤。如果邏輯複雜，請使用狀態圖。
✅ 第六階段：品質保證檢查
編碼之前，請根據既定的品質指標審查您的設計。此步驟可防止技術債在早期階段累積。
1. 耦合度與內聚度
這兩個是物件導向健康度最重要的指標。
- 高內聚度： 一個類別應具有單一且明確的目的。所有方法和屬性都應與該目的相關。
- 低耦合度： 一個類別不應過度依賴其他類別的內部細節。它應透過介面或公開 API 進行互動。
如果修改一個類別需要同時修改其他五個類別，則您的耦合度過高。這會使系統變得脆弱且難以維護。
2. SOLID 原則
雖然這些原則常被視為檢查清單，但它們是維持設計完整性的重要指南：
- 單一職責原則： 一個類別應僅有一個變更的理由。
- 開閉原則： 機體應對擴展開放，但對修改封閉。
- 里氏替換原則： 子類型必須能無條件替換其基類型而不破壞系統。
- 介面隔離原則： 客戶端不應被迫依賴它們不需要的介面。
- 依賴反轉原則： 應依賴抽象，而非具體實作。
📝 物件導向分析與設計（OOAD）總檢查清單
使用此表格在開啟開發環境前驗證您的設計。逐一勾選項目以確保完整性。
| 類別 | 檢查項目 | 狀態 |
|---|---|---|
| 需求 | 所有參與者與目標是否都已明確定義？ | ☐ |
| 需求 | 每個功能都有撰寫接受標準嗎？ | ☐ |
| 概念層 | 名詞是否已對應至類別？ | ☐ |
| 概念層 | 類別是否具有單一責任？ | ☐ |
| 結構 | 關係（聚合/組合）是否明確定義？ | ☐ |
| 結構 | 是否存在循環依賴的風險？ | ☐ |
| 行為 | 是否為複雜流程繪製了順序圖？ | ☐ |
| 行為 | 是否為長期存在的物件定義了狀態管理？ | ☐ |
| 品質 | 模組之間的耦合是否已最小化？ | ☐ |
| 品質 | 設計是否遵循SOLID原則？ | ☐ |
| 驗證 | 設計是否經過同儕審查？ | ☐ |
| 驗證 | 設計時是否考慮了邊界情況？ | ☐ |
🚫 應避免的常見陷阱
即使有檢查清單，某些陷阱仍會困住經驗豐富和缺乏經驗的工程師。了解這些陷阱有助於你避開它們。
1. 無血 Domain Model
不要建立僅作為資料容器並搭配 getter 和 setter 的類別。這是一種常見錯誤，將業務邏輯推入服務類別，導致領域物件空空如也。相反地，應將邏輯內嵌於擁有資料的物件中。一個銀行帳戶應知道如何提款()，而不僅僅是儲存餘額數字。
2. 過度設計
為尚未存在的場景設計模式很容易。不要為每一個可能的未來需求都建立介面。針對當前需求進行設計，但保持程式碼足夠彈性以適應變化。使用YAGNI（你不會需要它）原則來指導你的決策。
3. 忽略資料流
僅設計結構是不夠的。你必須了解資料如何在系統中流動。如果資料需要頻繁轉換，請考慮轉換發生的位置。將資料轉換靠近其來源進行，比將原始資料透過多層傳遞要好。
4. 透過具體類型產生緊密耦合
如果可能，不要在其他類別中建立具體類別的實例。應使用介面或抽象。這讓你日後能輕鬆替換實作，而無需重寫依賴程式碼。例如，注入一個電子郵件服務介面，而不是直接注入一個Gmail服務類別。
🔄 迭代與演進
設計不是一次性的事件。它是一個迭代的過程。隨著你撰寫程式碼，你會發現新的需求，或察覺到最初假設中的缺陷。這是很正常的。
- 持續重構： 如果你發現自己在複製貼上程式碼，請立即停止。建立一個方法或類別來處理該邏輯。
- 更新文件： 如果程式碼有變更，請更新你的圖表。過時的圖表比沒有圖表更糟糕，因為它會誤導未來的維護者。
- 尋求反饋：向資深工程師展示你的設計。他們曾經見過模式失敗的情況，能夠提供你可能錯過的洞見。
接受你的第一個設計不會完美。目標是創造一個容易理解且容易修改的設計。如果你能在五分鐘內向同事解釋你的設計，那麼你很可能走在正確的軌道上。
🔍 深入探討：依賴管理
OOAD中最困難的部分之一就是管理依賴關係。當一個物件依賴於另一個物件時，就會產生依賴。過多的依賴會形成一個難以理清的連接網絡。
1. 依賴注入
不要在另一個物件內部創建物件，而是將其傳入。這稱為依賴注入。它能降低耦合度，並使測試更容易。在測試時，你可以輕鬆地將真實的資料庫連接替換為模擬連接，而無需更改程式碼邏輯。
2. 服務定位器
避免使用全域的服務定位器。這會讓依賴關係變得隱蔽且難以追蹤。如果一個類別需要某個依賴，應該在建構函式或方法簽名中明確指出。
3. 模組邊界
定義模組之間的明確邊界。模組不應暴露其內部實作細節。應使用公開介面與其他模組進行溝通。這種封裝能保護系統的內部狀態。
🎓 關鍵概念總結
總結一下，以下是你的OOAD旅程中的核心要點：
- 分析為先：在構建解決方案之前，先理解問題。
- 類別作為物件：模擬現實世界的概念，而不僅僅是資料庫表格。
- 溝通：明確定義物件之間如何溝通。
- 品質指標：留意耦合度與內聚度。
- 迭代：願意在學習過程中調整你的設計。
遵循此檢查清單，你將從撰寫能運作的程式碼，轉向打造能持久的軟體工程。這種方法能增強你對自身能力的信心，並打造出能抵禦變化的系統。請記住，優秀的設計是無形的。只有當它缺失時，才會被注意到。
在下一個專案中，將此指南隨身攜帶。當你感到卡住時，就參考它。讓結構引導你的創意，而非束縛它。經過練習，這些步驟將變得自然而然，讓你能專注於以清晰與精確的方式解決複雜問題。
