Component Object Model
COMの初期の時代、オブジェクトがどのような機能を提供するのかということをクライアントから確認するためには、インスタンスを実際に生成して(IUnknownインタフェースの)QueryInterfaceメソッドを呼び出してみるしかなかった。
この検証方法は、特定の業務のために適切なコンポーネントを選択したり、オブジェクトが提供するメソッドの使用方法を開発者が理解できるようにしたりといったところで、多くのアプリケーションにとって不便であるということになった。
結果的にコンポーネントを完全に確認できるCOMタイプライブラリが導入された。タイプライブラリは、コンポーネントのCLSID、コンポーネント実装のインタフェースのIID、これらのインタフェースの各メソッドの解説といった情報を含んでいる。タイプライブラリは一般にVisual BasicやVisual StudioのようなRAD環境でクライアントアプリケーションの開発者を支援するために利用されている。
オブジェクトがサポートする、異なるインターフェイス間の型変換は、言語固有のキャスト構文ではなく、言語非依存のQueryInterfaceメソッドで行う。メソッド呼び出しをデリゲート(委譲)する形でサブオブジェクトの集合(アグリゲーションと呼ぶ)を生成する方法がCOM内における最適な継承方法である。
COMはプロトコルなどの仕様が公開されており、XPCOMのようなクロスプラットフォーム実装も存在するが、COMが主に利用されているのはMicrosoft Windows環境である。MonoにおけるCOM相互運用もMS COMおよびXPCOMを基盤としているが、機能およびサポート環境はまだ限定されている。
COMの前身はOLEである。COMは.NET Frameworkに置き換えられているものも多い。たとえば.NETはDCOMの代替として、Windows Communication Foundation (WCF) を通じてWebサービスをサポートする。WCFがXMLベースのSOAPメッセージを利用するのに対し、ネットワークで接続されたDCOMはバイナリの独自仕様フォーマットを利用する。しかし、Microsoft DirectXなどに代表されるように、ネイティブC++での利用を前提としたパフォーマンス重視のAPIは、依然として.NETではなくCOMが使われる傾向にある。
COMはまたソフトウェアコンポーネントシステムとしてCORBAやJava Beansと競合関係にある。