c++ - COM (コンポーネント オブジェクト モジュール) を使用する必要がありますか?

Question

数日前、私は COM を読み始めました。その後、私のチーム メンバーの 1 人が、これは古いテクノロジであり、現在は誰も使用していないと言いました。

私の質問は：

1) それが古い技術である場合、その代替手段は何ですか。

2) COM を使用する必要がないのはなぜですか。つまり、COM の欠点は何ですか。

Answer 1

COM は、C++ と同じように「古いテクノロジ」です。古いからといって、時代遅れというわけではありません。Microsoft がこれに戻ってくる理由 (Windows 8 はこれを大いに利用しています) は、比較的オーバーヘッドの少ないオブジェクト ベースのテクノロジであるためです。COM を使用する前に初期化する大きなランタイムはありません (ただし、必要に応じて、.NET CCW などのコンポーネントでランタイムを初期化できます)。

インターフェイス/実装の境界は厳密に分離されているため、オブジェクト指向の方法で Windows 機能を公開するのに役立ちます (Windows シェルは COM に基づいている DirectX と同様)。

COM は、COM とは何か、COM の上に構築されたものとは何かという一般的な誤解に悩まされています。ActiveX、DCOM、OLE、COM+ などは COM 上に構築されていますが、COM とは何かを定義していません。コア テクノロジとしての COM 自体は、比較的シンプルに保たれています。

COMは完璧ではないので、相対的に言います。アパートメント モデルは、アプリケーションがメッセージ キューをポンピングする必要があるクロス アパートメント マーシャリングなど、重大な問題を引き起こす可能性があります。90 年代後半には、人々は COM に夢中になり、すべてを COM コンポーネントから作成していたため、アプリケーションが不必要に複雑になりました。ただし、これは十分にテストされたテクノロジであり、適切に使用すると、特にサードパーティの機能を公開または使用する場合にうまく機能します。Windows API を本当に理解したい場合は、COM の仕組みを知る必要があります。

Answer 2

1) それが古い技術である場合、その代替手段は何ですか。

COMは確かに古いです。Microsoftの「代替」は.NETでした/.NETですが、CLRと一緒に遊ぶ必要があることを意味します(ネイティブC++は一緒に遊ぶことができず、これにはC++/CLIが必要になります)。最新の代替手段は現在、WinRT (Windows ランタイム) と呼ばれています。WinRT は現在、Windows 8 および Windows Server 2012 でのみ使用できます。最低レベルでは、WinRT は実際には COM ですが、Microsoft はその多くの落とし穴を再考しました。プラットフォームや言語に依存しない代替手段には、Google Protocol Buffers、Apache Thrift、SOAP などがあります。

2) COM を使用する必要がないのはなぜですか。つまり、COM の欠点は何ですか。

COM の主な目的は、プロセス間通信 (IPC) です。たとえば、2 つのプログラミング言語で記述された 2 つのアプリケーションがあり、それらが通信できるようにしたい場合、COM は (Windows 固有の) ソリューションです。COM は、90 年代に C++ と VB6 アプリケーション間の通信に広く使用されました。IPC の必要がない場合、COM の可能性はかなり低くなります。今日の職場では、COM を最も一般的に使用して、ネイティブ C++ アプリケーションと C# で記述されたマネージ .NET アプリケーションで IPC を実行しています。

Answer 3

Windows 8 メトロ アプリを作成するための WinRT ランタイム (現在は何と呼ばれていても...) である Microsoft の最新の大きな "テクノロジ" は、COM に完全に依存しているため、決して時代遅れではありません。