對象消息模型深度解析：從 C++ 指釖調用到 Method Missing 的 OOP 本質探索

開篇驚奇：空指針也能調用方法？

class A {
public:
    void Hello(const std::string& name) {
        std::cout << "hello " << name;
    }
};

int main() {
    A* pa = NULL;
    pa->Hello("world");  // 輸出 "hello world"，不崩潰！
    return 0;
}

為什麼？C++ 對象模型決定：非虛函數不佔用對象內存，編譯器將其轉為全局函數 void A_Hello(A* const this, ...)，this 為隱式第一參數。因函數體未用到 this，空指針也能跑通。

Alan Kay 的啟示：消息才是 OOP 核心

"Smalltalk is not only NOT its syntax or the class library, it is not even about classes. The big idea is 'messaging'."

消息模型強調：對象間通過發送消息交互，關注接口與協議而非內部狀態。牛.吃(草) 本質是向「牛」發送「吃」消息，附帶「草」參數。

主流語言對消息模型的背離

封裝的真相：類邊界 ≠ 對象邊界

// C# 反面教材
public class Account {
    private int _amount;
    public void Transfer(Account acc, int delta) {
        acc._amount += delta;  // 直接訪問另一對象私有字段！
        this._amount -= delta;
    }
}

這不違反「類封裝」（編譯期靜態邊界），但違反「對象封裝」（運行期動態邊界）。消息模型要求：只能通過消息改變對象狀態，內部結構對外完全不可知。

JavaScript 閉包實現真正的消息模型

function Set() {
    var _elements = arguments;  // 真正私有，外部不可見
    this.In = function(e) {
        for (var i = 0; i < _elements.length; ++i)
            if (_elements[i] == e) return true;
        return false;
    };
}

Set.prototype.Join = function(s2) {
    var s1 = this;
    var s = new Set();
    s.In = function(e) { return s1.In(e) && s2.In(e); }; // 僅通過接口交互
    return s;
};

這裡 s2 的內部結構完全隱藏，Join 僅通過 In 消息協作——這才是消息模型的精髓。

Method Missing：動態語言的殺手鐧
當發送未定義消息時：

  
靜態語言：編譯報錯
  
JavaScript：運行時拋異常
  
Ruby/Python/Groovy/C# 4.0+：調用 method_missing/__getattr__/TryInvokeMember


Ruby DSL 經典案例：Builder::XmlMarkup
builder = Builder::XmlMarkup.new
xml = builder.books { |b|
  b.book(:isbn => "14134") {
    b.title "Revelation Space"
    b.author "Alastair Reynolds"
  }
}

任意標籤名（books, book, title）皆為動態消息，由 method_missing 攔截構建 XML 樹——這在靜態語言中幾乎不可能優雅實現。

總結：三層對象模型的進化

  
C++ 對象模型：內存佈局、指針調用、編譯期綁定——關注機制
  
基於類的靜態模型：封裝、繼承、多態、類型安全——關注結構
  
消息模型：接口協議、動態分發、對象自治、Method Missing——關注交互本質

理解這三個層次，才能透過語法糖看到 OOP 的靈魂：對象是獨立的計算單元，通過消息協作構建系統。下次設計 API 時，請問自己：我在定義類，還是在設計消息協議？