透過參考計數管理物件存留期
在傳統物件系統中，物件的生命週期，也就是建立和刪除對象相關的問題，會由語言（或語言運行時間）或應用程式程式設計人員明確處理。
在由重複使用元件組成的不斷演變、分散建構的系統中，任何用戶端，甚至是任何程式設計人員，永遠都「知道」如何處理元件的存留期，就不再如此了。 對於具有適當安全性許可權的用戶端而言，透過簡單要求建立物件仍然相當容易，但對象刪除完全是另一回事。 當不再需要且應該刪除物件時，不一定清楚。 （熟悉 Java 等垃圾收集程式設計環境的讀者可能會意見不一;不過，Java 物件不會跨越計算機或甚至進程界限，因此垃圾收集僅限於生活在單一進程空間中的物件。此外，Java 會強制使用單一程式設計語言。即使原始用戶端是使用 物件完成，它也無法直接關閉對象，因為某些其他用戶端或用戶端可能仍有其參考。
若要確保不再需要物件的方法之一，就是完全依賴基礎通道，以在跨進程或跨通道物件的所有連線都消失時通知系統。 不過，基於數個原因，使用此方法的配置是不可接受的。 其中一個問題是，它可能需要跨進程/跨網路程序設計模型與單一進程程序設計模型之間的重大差異。 在跨進程/跨網路程序設計模型中，通訊系統會提供物件存留期管理所需的勾點，而在單一進程程序設計模型中，物件會直接連接，而不需要任何介入的通訊通道。 另一個問題是，此配置也可能導致一層系統提供的軟體，以干擾同進程案例中的元件效能。 此外，以明確監視為基礎的機制不會相應縮小至數千個或數百萬個物件。
COM 為這組問題提供了可調整且分散式的方法。 用戶端會在使用物件時和完成時告訴物件，而不再需要物件時會自行刪除。 此方法會要求所有物件都計算本身的參考。 Java 之類的程式設計語言原本就有自己的存留期管理配置，例如垃圾收集，可以使用 COM 的參考計數在內部實作和使用 COM 物件，讓程式設計人員避免處理它。
就如同應用程式必須釋放它已配置的記憶體一旦該記憶體不再使用，物件的用戶端會負責釋放該對象的參考，而不再需要該物件時。 在面向物件系統中，用戶端只能藉由提供物件釋放本身的指令來執行此動作。
當物件不再使用時，請務必解除分配。 困難在於判斷何時適合解除分配物件。 這很容易使用自動變數（在堆疊上配置變數），它們無法在宣告它們的區塊之外使用，因此編譯程式會在到達區塊結尾時解除分配它們。 如果是動態配置的 COM 物件，則由物件的用戶端決定何時不再需要使用物件，特別是多個用戶端可能同時使用的本機或遠端物件。 對象必須等到所有用戶端都完成之後，才能釋放它。 由於 COM 對像是透過介面指標操作，而且可由不同進程或其他電腦上的物件使用，所以系統無法追蹤物件的用戶端。
COM 判斷何時適合解除分配物件的方法是手動參考計數。 每個物件都會維護一個參考計數，以追蹤有多少個用戶端連線到它，也就是說，任何用戶端中任何介面都有多少指標存在。
如需詳細資訊，請參閱下列主題：
相關主題