一針見血：面向對象思維方法的本質——從現實世界建模而非機器實現

作者從 C 程式設計師轉型 Java 的親身經歷出發，深刻剖析面向對象設計的核心誤區：以機器實現視角（自底向上）替代現實世界建模視角（自頂向下）。文中通過發送廣告郵件、網頁計數器兩個生動案例，展示如何從「人類業務思維」提煉類設計，而非從「數據庫操作、協議細節」切入。

思維轉型的痛苦開端

習慣 C 簡潔高效的作者，初接觸 Java 時強烈排斥：運行慢、代碼冗長、簡單功能拆分多個類、層層調用。嘗試用 OOP 風格寫代碼仍覺得「不知如何提煉類、腦中千頭萬緒」，不自覺回歸面向過程思維。

案例一：發送廣告郵件——功能分解 vs 業務建模

面向過程思維（C 風格）：讀郵件內容 → 連數據庫 → 循環取地址 → 調用 sendmail 命令。全部塞入 main 流程。

錯誤的 OOP 嘗試（仍是機器視角）：

• 類 A：讀數據庫、取地址、調用 sendmail
• 類 B：讀郵件內容、MIME 編碼、加郵件頭
• 主類：解析參數、調用類 A

深度剖析：這三個類完全從「程式設計師如何實現功能」切分，已預設底層細節（數據庫、qmail、MIME），屬自底向上的機器視角。若改用 C 封裝兩個函數反而更清晰輕鬆——說明此設計未發揮 OOP 優勢。

案例二：網頁計數器——從用戶需求提煉類

程式設計師視角：解析 HTTP GET 參數 id → 查數據庫 → 計數+1 → 更新數據庫 → 輸出結果。全程圍繞技術細節。

非程式設計師（業務視角）會怎麼想？

「我需要一個計數器，功能：刷新頁面計數+1、可歸零、最好可設任意值（方便作弊）。」

完全不關心數據庫、HTTP、併發鎖等技術細節，純粹表達業務需求與邏輯。

正確的類設計：Counter 類

public class Counter {
    public int getCount(int id) {}        // 取計數值
    public void resetCounter(int id) {}   // 歸零
    public void setCount(int id, int currentCount) {} // 設定值
}

這才是面向對象精髓：類名源自現實世界名詞，方法對應業務動詞，封裝內部實現細節。數據庫操作、HTTP 解析、併發控制皆隱藏在類內部，對外呈現純粹業務語義介面。

核心結論

面向對象的精髓在於：考慮問題的思路從現實世界的人類思維習慣出發。 只要領會此點，就掌握了 OOP 思維方法。類設計應回答「領域專家需要什麼功能」，而非「我要怎麼操作數據庫」。這也是為何領域驅動設計（DDD）強調通用語言、豐富領域模型的根本原因。

這篇短文卻直擊靈魂，是無數從面向過程轉型面向對象開發者的必讀啟蒙。建議配合《領域驅動設計》《物件導向分析與設計》深度研習，完成思維範式的根本重構。