面向對象思維轉型：從過程式「自底向上」到領域驅動「自頂向下」

前言：思維陷阱與破局

C 程序員轉 Java 時，最大障礙不是語法，而是思維範式。習慣「先想數據結構、再寫函數、最後組裝 main」的自底向上過程式思維，導致寫出的 Java 代碼只是「帶類語法的 C」。本文通過兩個對比案例，演示如何建立自頂向下、領域驅動的 OO 思維。

案例一：發送廣告郵件 — 過程式 vs OO 分解

❌ 過程式思維 (自底向上，機器視角)

1. 讀取郵件內容 (I/O)
2. 連接數據庫 (JDBC)
3. 循環取郵箱地址 (ResultSet 遍歷)
4. 調用 sendmail 命令 (Runtime.exec)

Java 硬套版：三個類 —— DbSender(讀庫+發送)、MailBuilder(MIME編碼)、Main(參數解析)。本質仍是模塊化過程式，類只是函數容器，邏輯耦合在「如何實現」細節上。

✅ OO 思維 (自頂向下，業務視角)

問：業務需要什麼對象？它們有什麼行為？

• 郵件模板：render(Map<String,Object> data) → String
• 收件人列表：List<Recipient> loadAll()
• 郵件發送器：send(Mail mail, Recipient to) (封裝 SMTP/Sendmail/雲 API)
• 批量發送服務：batchSend(Template, List<Recipient>) (事務、重試、限流)

核心差異：類名來自業務名詞，方法名來自業務動詞，實現細節 (JDBC、MIME、命令行) 被封裝在私有方法或輔助類中，對外呈現純粹的領域語言。

案例二：網頁計數器 — 需求驅動建模

非程序員視角 (純業務需求)

「我需要一個計數器，刷新頁面加 1，能歸零，能設置任意值 (作弊用)。」

OO 建模直接映射需求

public class Counter {
    // 核心業務行為
    public int getCount(String id);        // 獲取計數
    public void increment(String id);      // 刷新頁面加 1 (隱含在 get 或單獨方法)
    public void reset(String id);          // 歸零
    public void setCount(String id, int v); // 設置任意值
}

使用端極簡調用

// count.cgi / Servlet
String id = request.getParameter("id");
Counter counter = new Counter(); // 或注入
int current = counter.getCount(id); // 內部自動 increment
response.getWriter().print(current);

對比：過程式建模

1. 從 HTTP 取 id
2. 查數據庫 SELECT count
3. count + 1
4. UPDATE 數據庫
5. 輸出 count

過程式建模洩露實現細節 (HTTP、SQL、更新邏輯) 到核心邏輯層，導致難以測試、難以替換存儲 (Redis/文件/分布式)、難以擴展 (緩存、限流)。

OO 思維三大轉型鑰匙

實戰練習：從需求文檔提取領域模型

1. 名詞提取法：閱讀需求，圈出業務名詞 (訂單、客戶、商品、優惠券、庫存...)。
2. 動詞歸屬法：每個動作歸屬哪個名詞 (「下單」→ Order.place()、「扣庫存」→ Inventory.reserve())。
3. 識別聚合根：哪些對象有獨立生命週期、外部只能通過根訪問 (Order 是根，OrderItem 是內部實體)。
4. 定義值對象：無標識、不可變、按值比較 (Money、Address、DateRange)。
5. 劃分限界上下文：大系統拆分微服務/模組邊界 (訂單上下文、支付上下文、用戶上下文)。

給 C/Java 程序員的轉型建議

1. 寫第一行代碼前，先畫領域模型圖 (UML 類圖或手繪草圖)。
2. 拒絕「Manager/Util/Helper」命名，強迫自己用業務名詞。
3. 私有方法承擔實現細節，公共方法只說「做什麼」，不說「怎麼做」。
4. 依賴注入而非 new：構造函數注入接口，測試時替換 Mock 實現。
5. 閱讀《領域驅動設計》《企業應用架構模式》，建立模式詞彙庫。

OO 不是語法糖，是認知升級。當你開始用業務語言思考、用領域模型建模、用接口契約解耦，你就真正進入了面向對象的世界。