Component Object Model
推移性とは、対称性と似ているが、インターフェイスBがインターフェイスAから取得でき、インターフェイスCがインターフェイスBから取得できる場合、インターフェイスCはインターフェイスAから取得できなければならないということである。
インターフェイスには、インターフェイスを実装した関数へのポインタをその宣言時の順に並べた仮想関数テーブルへのポインタが含まれている。この関数テーブル構造は、OLE 1.0のときからOLEシステムとの通信に使われていた。
COMはコンポーネント間の通信のためにほかにも多くの標準インターフェイスを定めている。たとえばデータストリームを管理するIStreamが挙げられる。これはファイルストリームのコンポーネントがファイルを読み書きする際に使うことが考えられる。IStreamのReadメソッドとWriteメソッドはストリームに対して読み取りと書き込みを行うことが想定される。他の例として、IOleObjectは、あるアプリケーションのデータオブジェクト内に別のアプリケーション向けのデータオブジェクトを埋め込むような複合文書に利用される。IOleObjectインターフェイスは、呼び出した側が呼び出し先コンポーネントとの画面表示上の境界を決められるメソッドや、「開く」あるいは「保存」などのユーザー操作(アクション)に対応する処理を実行することができるメソッドを持っている。
後者は新しいバージョンに対応するCOMクライアントを再作成する必要があるが、複数のバージョンを共存させることができ、バージョン間の互換性を考慮する必要はない。たとえばDirect3Dのバージョン7/8/9/10/11/12は、すべて異なるインターフェイスを持つ独立したCOMコンポーネントであり、同一コンピュータ上に共存できる。典型的にいって、COMにおける最良のアプローチは、機能を拡張するためには新しいインターフェイスを定義することである。なおCOMコンポーネントのマイナーバージョンアップの際は、通例既存のインターフェイスを継承して新たなインターフェイスを定義する手法が採られる。たとえばDirect3D 10.1あるいは11.1/11.2/11.3における各インターフェイスは、Direct3D 10.0あるいは11.0のインターフェイスからそれぞれ派生した新しいインターフェイスを定義する方法で機能拡張が行なわれている。
Windows XP以降では、「分離アプリケーションとSide-by-Sideアセンブリ」と呼ばれる仕組みを使い、レジストリではなくマニフェストファイルを使用してコンポーネント依存関係を解決することも可能である。この仕組みを用いることで、COMコンポーネントをシステム全体で共有せず、アプリケーションごとにプライベートアセンブリとして配布・運用することも可能となる。
全てのCOMコンポーネントはIUnknownと呼ばれるインターフェイスを継承する必要がある。また、全てのCOMインターフェイスはIUnknownから派生している。IUnknownは、AddRef / Release / QueryInterfaceという3つのメソッドを持っている。AddRefとReleaseはインターフェイスの生存期間を管理するための参照カウントを実装するメソッドである。そしてQueryInterfaceは、IIDを指定してコンポーネントが実装している他のインターフェイスを取得するメソッドである。これはC++のdynamic_castや、JavaおよびC#の型変換演算子に相当する。
COMコンポーネントのインターフェイスは、反射性、対称性、推移性を備えている必要がある。反射性とは、あるインターフェイスから、QueryInterfaceをそのインターフェイス自身を表すIIDを与えて呼び出すと、返ってくるインターフェイスは元と同じものでなければならないということである。対称性とは、インターフェイスAからQueryInterfaceでインターフェイスBが取得できる場合、インターフェイスBからインターフェイスAが取得できなければならないということである。