苛評VCL: 不滿意TObject的設計

在李維的《inside VCL》中詳細描述了VCL中TObject的地位。是的Borland的工程師們有心將Delphi語言做成pure language。所以你幾乎可以看到TObject的所有pure pascal的實現。

更重要的，你應該會發現。Delphi將代碼的所有運行機制都暴露在我們面前。這也就是Delphi的TObject和C++中的Object以及C#的Object有很大不同的地方。

Delphi將整個語言的機制都在TObject上實現了。訊息機制、介面機制、物件導向機制（多態）等等你都可以從TObject的實現代碼中看到啟動並執行全部流程。

不管TObject如何優秀，可是TObject正如Borland一樣，在它身上總是看到受制於MS的影子。特別是介面機制。我有兩點認為TObject的設計不好。

對象指標和介面指標並不是同一個地址
對象和介面不可以混用
先說說我第一個不滿意的地方。說是第一，並不表示是“最”的意思。只是代表“最先”的意思。

在Delphi的TObject中，類在實現了介面之後，其建立的執行個體中，對象指標和介面指標並不是同一個地址。這個可能大家沒有注意到，但是主要通過簡單的例子（取兩個指標的地址）就可以發現這個現象。

你可能不會在意這個差異。是的，其實也沒什麼，不是同一個地址，代碼照樣可以工作。在對象的記憶體執行個體模型中，介面的指標直接儲存在屬性後面（如果存在繼承，可能會出現交錯的）。因為TObject設計的時候，兩個地址不在一起，那麼就存在兩個問題：

如果從對象轉換到介面
如何從介面轉換到對象
稍微知道物件模型的人，就應該知道對象調用虛擬方法表的過程。只有對象指標可以指向VMT。另外，在介面存取方法的實現代碼的時候，也需要傳入對象指標。這是為什嗎？我們知道，一個對象的方法中，有一個隱含的指標，我們一般稱它為Self指標。只要不是class function，那麼這個Self指標就是指向對象執行個體的指標。所以在代碼的調用過程中，必然有這個轉換。

TObject提供的AS操作，可以完成第1個轉換，但是可惜的是，TObject並沒有提供一個公開的方法來負責第2個轉換。這是我認為TObject在這方面設計不好的原因。（JCL程式碼程式庫中有第2個轉換的代碼）

第二個我不滿意的地方就是TObject在生存期管理上，沒有做到和介面一致。我相信這也是許多使用Delphi介面的同志們一致的想法。雖然我們現在看到Java和C#都已經做到這點，可不能不指出的是，在Delphi中，對象和介面不可以混用！

我並不是奢求TObject的生存期可以自管理。畢竟，我還是習慣了“誰建立誰釋放”的規則。可是一旦到了介面和對象混合使用的時候，就發生了問題。

這雖然可以解釋為介面是Delphi為了迎合COM而後加上的。我們今天卻應該來設計一下一種規則，來解決介面混用的問題。我認為可以有一種簡單的方式：TObject在Free的時候，發現其介面引用計數不為0的時候，不會Destroy。

目前我們無法做到這點，這是因為Destroy是Delphi預設做的，也就是說，只要調用了Free方法，Destroy必然發生。我們無法完美地改變這個現實。也正因為此，我才認為必須在設計TObject的時候，將這個考慮進去！

OK。嘗試重新審視VCL中的各個基礎類，其實有點大膽。所以用“苛評”這個詞來做標題，表明這完全是我的苛刻，VCL的設計是非常棒的。不過也算是我使用6年Delphi的一點回報吧。以後還會繼續苛評其他類。希望大家繼續關注。