Delphi COM程式設計介紹

 軟體重用是業界追求的目標，人們一直希望能夠像搭積木一樣隨意“裝配”應用程式，元件物件就充當了積木的角色。所謂元件物件，實際上就是預定義好的、能完成一定功能的服務或介面。問題是，這些元件物件如何與應用程式、如何與其他元件物件共存並相互通訊和互動?這就需要制定?個規範，讓這些元件物件按統一的標準方式工作。 
COM是個二進位制規範，它與原始碼無關。這樣，即使COM物件由不同的程式語言建立，執行在不同的程式空間和不同的作業系統平臺，這些物件也能相互通訊。COM既是規範，也是實現，它以COM庫(OLE32.dll和貼OLEAut32.dll)的形式提供了訪問COM物件核心功能的標準介面以及一組API函式，這些API函式用於建立和管理COM物件。COM本質上仍然是客戶伺服器模式。客戶(通常是應用程式)請求建立COM物件並通過COM物件的介面操縱COM物件。伺服器根據客戶的請求建立並管理COM物件。客戶和伺服器這兩種角色並不是絕對的。 
元件物件與一般意義上的物件既相似也有區別。一般意義上的物件是一種把資料和操縱資料的方法封裝在一起的資料型別的例項，而元件物件則使用介面(Interface)而不是方法來描述自己並提供服務。所謂介面，其精確定義是“基於物件的一組語義上相關的功能”，實際上是一個純虛類，真正實現介面的是介面物件)(Interface Object)。一個COM物件可以只有一個介面，例如Wndows 95／98外殼擴充套件；也可以有許多介面，例如ActiveX控制元件一般就有多個介面，客戶可以從很多方面來操縱ActiveX控制元件。介面是客戶與伺服器通訊的唯一途徑。如果一個元件物件有多個介面，則通過一個介面不能直接訪問其他介面。但是，COM允許客戶呼叫COM庫中的QueryInterface()去查詢元件物件所支援的其他介面。從這個意義上講，元件物件有點像介面物件的經紀人。 
在呼叫QueryInterface()後，如果元件物件正好支援要查詢的介面，則QueryInterface()將返回該介面的指標。如果元件物件不支援該介面，則QueryInterface()將返回一個出錯資訊。 
所以，QueryInterface()是很有用的，它可以動態瞭解元件物件所支援的介面。介面是團向物件程式設計思想的一種體現，它隱藏了COM物件實現服務的細節。COM物件可以完全獨立於訪問它的客戶，只要介面本身保持不變即可。如果需要更新介面，則可以重新定義一個新的介面，對於使用老介面的客戶來說，程式碼得到了最大程度的保護。

Delphi通過嚮導可以非常迅速和方便的直接建立實現COM物件的程式碼，但是整個COM實現的過程被完全的封裝，甚至沒有VCL那麼結構清晰可見。

一個沒有C++下COM開發經驗甚至沒有接觸過COM開發的Delphi程式設計師，也能夠很容易的按照教程設計一個介面， 
但是，恐怕深入一想，連生成的程式碼代表何種意義，哪些能夠定製都不清楚。前幾期 “DELPHI下的COM程式設計技術”一文已經初步介紹了COM的一些基本概念，我則想談一些個人的理解，希望能給對Delphi下COM程式設計有疑惑的朋友帶來幫助。

COM (元件物件模型 Component Object Model)是一個很龐大的體系。簡單來說，COM定義了一組API與一個二進位制的標準，讓來自不同平臺、不同開發語言的獨立物件之間進行通訊。COM物件只有方法和屬性，幷包含一個或多個介面。這些介面實現了COM物件的功能，通過呼叫註冊的COM物件的介面，能夠在不同平臺間傳遞資料。

COM游標準和細節就可以出幾本大書。這裡避重就輕，僅僅初步的解釋Delphi如何進行COM的封裝及實現。對於上述COM技術經驗不足的Delphi程式開發者來說， 
Delphi通過模版生成的程式碼就像是給你一幅抽象畫照著畫一樣，畫出來了卻不一定知道畫的究竟是什麼，也不知該如何下手畫自己的東西。本文能夠幫助你解決這類疑惑。

再次講解一些概念 
“DELPHI下的COM程式設計技術”一文已經介紹了不少COM的概念，比如GUID、CLSID、IID，引用計數，IUnKnown介面等，下面再補充一些相關內容：

COM與DCOM、COM+、OLE、ActiveX的關係

DCOM（分散式COM）提供一種網路上訪問其他機器的手段，是COM的網路化擴充套件，可以遠端建立及呼叫。COM+是Microsoft對COM進行了重要的更新後推出的技術，但它不簡單等於COM的升級，COM+是向後相容的，但在某些程度上具有和COM不同的特性，比如無狀態的、事務控制、安全控制等等。

以前的OLE是用來描述建立在COM體系結構基礎上的一整套技術，現在OLE僅僅是指與物件連線及嵌入有關的技術；ActiveX則用來描述建立在COM基礎上的非COM技術，它的重要內容是自動化（Automation），自動化允許一個應用程式（稱為自動化控制器）操縱另一個應用程式或庫（稱為

自動化伺服器）的物件，或者把應用程式元素暴露出來。

由此可見COM與以上的幾種技術的關係，並且它們都是為了讓物件能夠跨開發工具跨平臺甚至跨網路的被使用。

Delphi下的介面

Delphi中的介面概念類似C++中的純虛類，又由於Delphi的類是單繼承模式（C++是多繼承的），即一個類只能有一個父類。介面在某種程度上

可以實現多繼承。介面類的宣告與一般類宣告的不同是，它可以象多重繼承那樣，類名 = class (介面類1，介面類2… )，然後被宣告的介面類則過載繼承類的虛方法，來實現介面的功能。

以下是IInterface、IUnknown、IDispatch的宣告，大家看出這幾個重要介面之間是什麼樣的聯絡了嗎？任何一個COM物件的介面，最終都是從IUnknown繼承的，而Automation物件，則還要包含IDispatch，後面DCOM部分我們會看到它的作用。

IInterface = interface
  ['{00000000-0000-0000-C000-000000000046}']
  function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
  function _AddRef: Integer; stdcall;
  function _Release: Integer; stdcall;
end;

IUnknown = IInterface;

IDispatch = interface(IUnknown)
  ['{00020400-0000-0000-C000-000000000046}']
  function GetTypeInfoCount(out Count: Integer): HResult; stdcall;
  function GetTypeInfo(Index, LocaleID: Integer; out TypeInfo): HResult; stdcall;
  function GetIDsOfNames(const IID: TGUID; Names: Pointer;
    NameCount, LocaleID: Integer; DispIDs: Pointer): HResult; stdcall;
  function Invoke(DispID: Integer; const IID: TGUID; LocaleID: Integer;
    Flags: Word; var Params; VarResult, ExcepInfo, ArgErr: Pointer): HResult; stdcall;
end;

對照“DELPHI下的COM程式設計技術”一文，可以明白IInterface中的定義，即介面查詢及引用記數，這也是訪問和呼叫一個介面所必須的。

QueryInterface可以得到介面控制程式碼，而AddRef與Release則負責登記呼叫次數。

COM和介面的關係又是什麼呢？COM通過介面進行元件、應用程式、客戶和伺服器之間的通訊。COM物件需要註冊，而一個GUID則是作為識別介面的唯一名字。

假如你建立了一個COM物件，它的宣告類似 Txxxx= class(TComObject, Ixxxx)，前面是COM物件的基類，後面這個介面的宣告則是： Ixxxx = interface(IUnknown)                    。所以說IUnknown是Delphi中COM物件介面類的祖先。到這一步，我想大家對介面類的來歷已經有初步瞭解了。

聚合

介面是COM實現的基礎，介面也是可繼承的，但是介面並沒有實現自己，僅僅只有宣告。那麼怎麼使COM物件對介面的實現得到重用呢？答案就是聚合。聚合就是一個包含物件（外部物件）建立一個被包含物件（內部物件），這樣內部物件的介面就暴露給外部物件。

簡單來說，COM物件被註冊後，可以找到並呼叫介面。但介面不是僅僅有個定義嗎，它必然通過某種方式找到這個定義的實現，即介面的“實現類”的方法，這樣才最終通過外部的介面轉入進行具體的操作，並通過介面返回執行結果。

程式內與程式外（In-Process, Out-Process）

程式內的介面的實現基礎是一個DLL，程式外的介面則是建立在應用程式（EXE）上的。通常我們建立程式外介面的目的主要是為了方便除錯（跟蹤DLL是件很麻煩的事），然後在將程式碼改為程式內釋出。因為程式內比程式外的執行效率會高一些。(也就是先建立程式內的介面，再將其改為程式內釋出。）

COM物件建立在伺服器的程式空間。如果是EXE型伺服器，那麼伺服器和客戶端不在同一程式；如果是DLL型伺服器，則伺服器和客戶端就是一個程式。所以程式內還能節省記憶體空間，並且減少建立例項的時間。

StdCall與SafeCall

Delphi生成的COM介面預設的方法函式呼叫方式是stdcall而不是預設的Register。這是為了保證不同語言編譯器的介面相容。

雙重介面（在後面講解自動化時會提到雙重介面）中則預設的是SafeCall。它的意義除了按SafeCall約定方式呼叫外，還將封裝方法以便向呼叫者返回HResult值。SafeCall的好處是能夠捕獲所有異常，即使是方法中未被程式碼處理的異常，也可以被外套處理並通過HResult返回給呼叫者。

WideString等一些有差異的型別

介面定義中預設的字元引數或返回值將不再是String而是WideString。WideString 是Delphi中符合OLE 32-bit版本的Unicode型別，當是字元

時，WideString與String幾乎等同，當處理Unicode字元時，則會有很大差別。聯想到COM本身是為了跨平臺使用，可以很容易的理解為什麼資料通訊時需要使用WideString型別。

同樣的道理，integer型別將變成SYSINT或者Int64、SmallInt或者Shortint，這些細微的變化都是為了符合規範。

通過嚮導生成基礎程式碼

開啟建立新工程嚮導（選單“File-New-Other”或“New Items按鈕”），選擇ActiveX頁。先建立一個ActiveX Library。編譯後即是個DLL檔案（程式內）。然後在同樣的頁面再建立一個COM Object。

接著你將看到如下向導，除了填寫類名外（介面名會自動根據類名填充），建立有 
例項模式（Instancing）和執行緒模式（Threading Model）的選項。

例項模式->>決定客戶端請求後，COM物件如何建立例項：

Internal：供COM物件內部使用，不會響應客戶端請求，只能通過COM物件內部的其他方法來建立；

Single Instance：不論當前系統內部是否存在相同COM物件，都會建立一個新的程式及獨立的物件例項；

Mulitple Instance：如果有多個相同的COM物件，只會建立一個程式，多個COM物件的例項共享公共程式碼，並擁有自己的資料空間。

Single/ Mulitple Instance有各自的優點，Mulitple雖然節省了記憶體但更加費時。即Single模式需要更多的記憶體資源，而Mulitple模式需要更多的CPU資源，且Single的例項響應請求的負荷較為平均。該引數應根據伺服器的實際需求來考慮。

執行緒模式有五種：

Single：僅單執行緒，處理簡單，吞吐量最低；

Apartment：COM程式多執行緒，COM物件處理請求單執行緒；

Free：一個COM物件的多個例項可以同時執行。吞吐量提高的同時，也要求對COM物件進行必要的保護，以避免多個例項衝突；

Both：同時支援Aartment和Free兩種執行緒模式。

Neutral：只能在COM+下使用。

雖然Free和Both的效率得到提高，但是要求較高的技巧以避免衝突（這是很不容易除錯的），所以一般建議使用Delphi的預設方式。

型別庫編輯器（Type Library）

假設我們建立一個叫做TSample的類和ISample的介面（如圖），然後使用型別庫編輯器建立一個方法GetCOMInfo（在右邊樹部分點選右鍵彈出

選單選擇New-Method或者點選上方按鈕），並於左邊Parameters頁面建立兩個引數（ValInt : Integer , ValStr : String），返回值為BSTR。如圖：

可以看到，除了常用型別外，引數和返回值還可以支援很多指標、OLE物件、介面型別。建立普通的COM物件，其Returen Type是可以任意的，

這是和DCOM的一個區別。

雙擊Modifier列彈出視窗，可以選擇引數的方式：in、out分別對應const、out定義，選擇Has Default Value可設定引數預設值。

Delphi生成程式碼詳解

點選重新整理按鈕重新整理後，上面型別庫編輯器對應的Delphi自動生成的程式碼如下：

unit uCOM;

{$WARN SYMBOL_PLATFORM OFF}
interface
uses
  Windows, ActiveX, Classes, ComObj, pCOM_TLB, StdVcl;

type
  TSample = class(TTypedComObject, ISample)
  protected
    function GetCOMInfo(ValInt: SYSINT; const ValStr: WideString): WideString;  stdcall;
  end;

implementation

uses ComServ;

function TSample.GetCOMInfo(ValInt: SYSINT; const ValStr: WideString): WideString;
begin

end;

initialization
  TTypedComObjectFactory.Create(ComServer, TSample, Class_Sample, ciMultiInstance, tmApartment);

end.

引用單元

有三個特殊的單元被引用：ComObj，ComServ和pCOM_TLB。ComObj裡定義了COM介面類的父類TTypedComObject和

類工廠類 TTypedComObjectFactory（分別從TComObject和TComObjectFactory繼承[加了Typed]，早期版本如Delphi4建立的COM，就直接從TcomObject繼承和使用TComObjectFactory了）； ComServ單元裡面定義了全域性變數ComServer: TComServer[真的有這個]，它是從TComServerObject繼承的，關於這個變數的作用，後面將會提到。

這幾個類都是delphi實現COM物件的比較基礎的類，TComObject（COM物件類）和TComObjectFactory（COM物件類工廠類）本身就是IUnknown的

兩個實現類，包含了一個COM物件的建立、查詢、登記、註冊等方面的程式碼。TComServerObject則用來註冊一個COM物件的服務資訊。

介面定義說明

再看介面類定義TSample = class(TTypedComObject, ISample)。到這裡，已經可以通過涉及的父類的作用大致猜測到TSample是如何建立並注

冊為一個標準的COM物件的了。那麼介面ISample又是怎麼來的呢？pCOM_TLB單元是系統自動建立的，其名稱加上了_TLB，它裡面包含了ISample

= interface(IUnknown)的介面定義。前面提到過，所有COM介面都是從IUnknown繼承的。

在這個單元裡我們還可以看到三種ID（型別庫ID、IID及COM註冊所必須的CLSID）的定義：LIBID_pCOM，IID_ISample和CLASS_Sample。關鍵是

這時介面本身僅僅只有定義程式碼而沒有任何的實現程式碼，那介面建立又是在何處執行的？_TLB單元裡還有這樣的程式碼：

CoSample = class
  class function Create: ISample;
  class function CreateRemote(const MachineName: string): ISample;
end;

class function CoSample.Create: ISample;
begin
  Result := CreateComObject(CLASS_Sample) as ISample;
end;

class function CoSample.CreateRemote(const MachineName: string): ISample;
begin
  Result := CreateRemoteComObject(MachineName, CLASS_Sample) as ISample;
end;

由Delphi的嚮導和型別編輯器幫助生成的介面定義程式碼，都會繫結一個“Co+類名”的類，它實現了建立介面例項的程式碼。

CreateComObject和CreateRemoteComObject 
函式在ComObj單元定義，它們就是使用CLSID建立COM/DCOM物件的函式！

初始化：註冊COM物件的類工廠

類工廠負責介面類的統一管理——實際上是由支援IClassFactory介面的物件來管理的。類工廠類的繼承關係如下：

IClassFactory = interface(IUnknown)

TComObjectFactory=class(TObject,IUnknown,IClassFactory,IClassFactory2) TTypedComObjectFactory = class(TComObjectFactory)

我們知道了介面ISample是怎樣被建立的，介面實現類TSample又是如何被定義為COM物件的實現類。現在解釋它是怎麼被註冊，以及何時建立的。

這一切的小把戲都在最後Delphi單元裡的initialization的部分，這裡有一條類工廠建立的語句。

Initialization是Delphi用於初始化的特殊部分，此部分的程式碼將在整個程式啟動的時候首先執行。回顧前面的內容並觀察一下TTypedComObjectFactory的引數：

【ComServer是用於註冊/撤消註冊COM服務的物件，TSample是介面實現類，Class_Sample是介面唯一對應的GUID，ciMultiInstance是例項模式，tmApartment是執行緒模式。一個COM物件應該具備的特徵和要素都包含在了裡面！】

那麼COM物件的管理又是怎麼實現的呢？在ComObj單元裡面可以見到一條定義function ComClassManager: TComClassManager;

這裡TComClassManager顧名思義就是COM物件的管理類。任何一個祖先類為TComObjectFactory的物件被建立時，其Create裡面會執行這樣一句：

ComClassManager.AddObjectFactory(Self);

AddObjectFactory方法的原形為procedure TComClassManager.AddObjectFactory(Factory: TComObjectFactory);相對應的還有

RemoveObjectFactory方法。具體的程式碼我就不貼出來了，相信大家已經猜測到了它的作用——將當前物件（self）加入到ComClassManager管理的物件鏈（FFactoryList）中。

封裝的祕密

讀者應該還有最後一個疑問：假如伺服器通過類工廠的註冊以及GUID確定一個COM物件，那當客戶端呼叫的時候，伺服器是如何啟動包含COM物件的程式的呢？

當你建立ActiveX Library的工程的時候，將發現一個和普通DLL模版不同的地方——它定義了四個輸出例程：

exports

             DllGetClassObject,

             DllCanUnloadNow,

             DllRegisterServer,

             DllUnregisterServer;

這四個例程並不是我們編寫的，它們都在ComServ單元例實現。單元還定義了類TComServer，並且在初始化部分建立了類的例項，即前面提到過的全域性變數ComServer。

例程DllGetClassObject通過CLSID得到支援IClassFactory介面的物件；例程DllCanUnloadNow判斷DLL是否可從記憶體解除安裝；DllRegisterServer

和DllUnregisterServer負責DLL的註冊和解除註冊，其具體的功能由ComServer實現。

介面類的具體實現

好了，現在自動生成程式碼的來龍去脈已經解釋清楚了，下一步就是由我們來新增介面方法的實現程式碼。在function TSample.GetCOMInfo的部分

新增如下程式碼。我寫的例子很簡單，僅僅是根據傳遞的引數組織一條字串並返回。以此證明介面正確呼叫並執行了該程式碼：

function TSample.GetCOMInfo(ValInt: SYSINT; const ValStr: WideString): WideString;
const
  Server1 = 1;
  Server2 = 2;
  Server3 = 3;
var
  s: string;
begin
  s := ' This is COM server: ';
  case ValInt of
    Server1: s := s + ' Server1 ';
    Server2: s := s + ' Server2 ';
    Server3: s := s + ' Server3 ';
  end;
  s := s + #13 + #10 + ' Execute client is ' + ValStr;
  Result := s;
end;

註冊、建立COM物件及呼叫介面

隨便建立一個Application用於測試上面的COM。必要的程式碼很少，建立一個介面的例項然後執行它的方法。當然我們得先行註冊COM，否則呼叫

根據CLSID找不介面的話，將報告“無法向登錄檔寫入項”。如果介面定義不一致，則會報告“Interface not supported”。

編譯上面的這個COM工程，然後選擇選單“Run – Register ActiveX Server”，或者通過Windows下system/system32目錄中的regsvr32.exe程式註冊編譯好的DLL檔案。regsvr32的具體引數可以通過regsvr32/？來獲得。對於程式外（EXE型）的COM物件，執行一次應用程式就註冊了。

提示DLL註冊成功後，就應該可以正確執行下列客戶端程式了：

uses ComObj, pCOM_TLB;

procedure Ttest.Button1Click(Sender: TObject);
var
  COMSvr: ISample;
  retStr: string;
begin
  COMSvr := CreateComObject(CLASS_Sample) as ISample;
  if COMSvr <> nil then
  begin
    retStr := COMSvr.GetCOMInfo(2, ' client 2 ');
    showmessage(retStr);
    COMSvr := nil;
  end else
    showmessage(' ?¡§??¡§2??????¡ì2?3¡§|1| ');
end;

最終值是從當前程式外的一個“介面”返回的，我們甚至可以不知道這個介面的實現！第一次接觸COM的人，成功執行此程式並彈出對話方塊後，

也許會體會到一種技術如斯奇妙的感覺，因為你僅僅呼叫了“介面”，就可以完成你猜測中的東西。

建立一個分散式DCOM（自動化介面）

IDispatch

在delphi6之前的版本中，所有介面的祖先都是IUnknown，後來為了避免跨平臺操作中介面概念的模糊，又引入了IInterface介面。

使用嚮導生成DCOM的步驟和COM幾乎一致。而生成的程式碼僅將介面類的父類換為TAutoObject，類工廠類換為TAutoObjectFactory。這其實沒有

太大的不同，因為TAutoObject等於是一個標準COM外加IDispatch介面，而TAutoObjectFactory是從TTypedComObjectFactory直接繼承的：

TAutoObject = class(TTypedComObject, IDispatch)

TAutoObjectFactory = class(TTypedComObjectFactory)

自動化伺服器支援雙重介面，而且必須實現IDispatch。因討論範疇限制，本文只能簡單提出，IDispatch是DCOM和COM技術實現上的一個重要區

別。開啟_TLB.pas單元，可以找到Ixxx = interface(IDispatch)和Ixxx = dispinterface的定義，這在前面COM的例子裡面是沒有的。

建立過程中的差異

使用型別庫編輯器的時候，有兩處和COM不同的地方。首先Return Type必須選擇HRESULT，否則會提示錯誤，這是為了滿足雙重介面的需要。當

Return Type選擇HRESULT後，你會發現方法定義將變成procedure（過程）而不是預想中的function（函式）。

怎麼才能讓方法有返回值呢？還需要在Parameters最後多新增一個引數，然後將該引數改名與方法名一致，設定引數型別為指標（如果找不到

某種型別的指標型別，可以直接在型別後面加*，如圖，BSTR*是BSTR的指標型別）。最後在Modifier列設定Parameter Flags為RetVal，同時

Out將被自動選中，而In將被取消。

重新整理後，得到下列程式碼。新增方法的具體實現，大功告成：

             TSampleAuto = class(TAutoObject, ISampleAuto)

             protected

               function GetAutoSerInfo(ValInt: SYSINT;const ValStr: WideString): WideString; safecall;

             end;

遠端介面呼叫

遠端介面的呼叫需要使用CreateRemoteComObject函式，其它如介面的宣告等等與COM介面呼叫相同。CreateRemoteComObject函式比

CreateComObject 多了一個引數，即伺服器的計算機名稱，這樣就比COM多出了遠端呼叫的查詢能力。前面“介面定義說明”一節的程式碼可以對

照CreateComObject、CreateRemoteComObject的區別。

自定義COM的物件

介面一個重要的好處是：釋出一個介面，可以不斷更新其功能而不用升級客戶端。因為不論應用升級還是業務改變，客戶端的呼叫方式都是一

致的。

既然我們已經弄清楚Delphi是怎樣實現一個介面的，那能否不使用嚮導，自己定義介面呢？這樣做可以用一個介面繼承出不同的介面實現類，

來完成不同的功能。同時也方便了小組開發、客戶端開發、程式內/外同步編譯以及除錯。

介面單元：xxx_TLB.pas

前面略講了介面的定義需要注意的方面。介面除了沒有例項化外，它與普通類還有以下區別：介面中不能定義欄位，所有屬性的讀寫必須由方

法實現；介面沒有構造和解構函式，所有成員都是public；介面內的方法不能定義為virtual，dynamic，abstract，override。

首先我們要建立一個介面。前面講過介面的定義只存在於一個地方，即xxx_TLB.pas單元裡面。使用型別庫編輯器可以產生這樣一個單元。還是

在新建專案的ActiveX頁，選擇最後一個圖示（Type Library）開啟型別庫編輯器，按F12鍵就可以看到TLB檔案（儲存為.tlb）了。沒有定義任

何介面的時候，TLB檔案裡除了一大段註釋外只定義了LIBID（型別庫的GUID）。假如關閉了型別庫編輯器也沒有關係，可以隨時通過選單View

– Type Library開啟它。

先建立一個新介面（使用嚮導的話這步已經自動完成了），然後如前面操作一樣建立方法、屬性…生成的TLB檔案內容與嚮導生成_TLB單元大致

相同，但僅有定義，缺乏“co+類名”之類的介面建立程式碼。

再觀察程式碼，將發現介面是從IDispatch繼承的，必須將這裡的IDispatch改為IUnknown。儲存將會得到.tlb檔案，而我們想要的是一個單元

（.pas）檔案，僅僅為了宣告介面，所以把程式碼拷貝複製並儲存到一個新的Unit。

自定義CLSID

從註冊和呼叫部分可以看出CLSID的重要作用。CLSID是一個GUID（全域性唯一介面表示符），用來標識物件。GUID是一個16個位元組長的128位二進

制資料。Delphi宣告一個GUID常量的語法是：

             Class_XXXXX : TGUID = ''''{xxxxxxxx-xxxxx-xxxxx-xxxxx-xxxxxxxx}'''';

在Delphi的編輯介面按Ctrl+Shift+G鍵可以自動生成等號後的資料串。GUID的宣告並不一定在_TLB單元裡面，任何地方都可以宣告並引用它。

介面類宣告與實現

新建一個ActiveX Library工程，加入剛才定義的TLB單元，再新建一個Unit。我的TLB單元取名為MyDef_TLB.pas，定義了一個介面

IMyInterface = interface(IUnknown)，以及一個方法function SampleMethod(val: Smallint): SYSINT; safecall;現在讓我們看看全部介面

類宣告及實現的程式碼：

unit uMyDefCOM;

interface

uses ComObj, Comserv, ActiveX, MyDef_TLB;

const
  Class_MySvr: TGUID = '{1C0E5D5A-B824-44A4-AF6C-478363581D43}';

type
  TMyIClass = class(TComObject, IMyInterface)
    procedure Initialize; override;
    destructor Destroy; override;
  private
    FInitVal: word;
  public
    function SampleMethod(val: Smallint): SYSINT; safecall;
  end;

  TMySvrFactory = class(TComObjectFactory)
    procedure UpdateRegistry(Register: Boolean); override;
  end;

implementation

procedure TMyIClass.Initialize;
begin
  inherited;
  FInitVal := 100;
end;

destructor TMyIClass.Destroy;
begin
  inherited;
end;

function TMyIClass.SampleMethod(val: Smallint): SYSINT;
begin
  Result := val + FInitVal;
end;

procedure TMySvrFactory.UpdateRegistry(Register: Boolean);
begin
  inherited;
  if Register then
  begin
    CreateRegKey('MyApp\' + ClassName, 'GUID', GUIDToString(Class_MySvr));
  end  else
  begin
    DeleteRegKey('MyApp\' + ClassName);
  end;
end;

initialization
  TMySvrFactory.Create(ComServer, TMyIClass, Class_MySvr,  'MySvr', '', ciMultiInstance, tmApartment);

end.

Class_MySvr是自定義的CLSID，TMyIClass是介面實現類，TMySvrFactory是類工廠類。

COM物件的初始化

procedure Initialize是介面的初始化過程，而不是常見的Create方法。當客戶端建立介面後，將首先執行裡面的程式碼，與Create的作用一樣

。一個COM物件的生存週期內，難免需要初始化類成員或者設定變數的初值，所以經常需要過載這個過程。

相對應的，destructor Destroy則和類的標準析構過程一樣，作用也相同。

類工廠註冊

在程式碼的最後部分，假如使用TComObjectFactory來註冊，就和前面所講的完全一樣了。我在這裡刻意用類TMySvrFactory繼承了一次，並且重

載了UpdateRegistry 方法，以便向登錄檔中寫入額外的內容。這是種小技巧，希望大家根據本文的思路，摸清COM/DCOM物件的Delphi實現結構

後，可以舉一反三。畢竟隨心所欲的控制COM物件，能提供的功能遠不如此。