Model)とは、バイナリモジュール同士(EXEやDLL)がインターフェースという手段で通信するための規格です。COMもそうした中の一種であると考えて問題ありません。これに対してCOMは通信をインターフェースで実現しているというだけのことです。COMを理解することは建前の上では、通信手法の1つを理解するということに過ぎません。それでは、COMによる通信を行うつもりがない場合はCOMについて理解しなくても問題ないのでしょうか。答えは残念ながらNOになります。COMインターフェースという形で提供されることが相当数あるからです。開発者は嫌でもCOMを理解しなければならないのが現状になっているのです。COMというものをそこまで新しい何かと考える必要はありません。COMは、C++言語をベースとした技術になっているからです。C++言語はクラスを定義し、そのクラスのインスタンスをオブジェクトとして定めていました。サーバーは自身の機能をメソッドとして含んだクラスを定義します。次のようなクラスを定義したいと思うはずです。クライアントが呼び出せるようにpublicにする。これはクラス内部で使用するためprivateにする。クライアントはサーバーの機能を利用できるように思えます。このようなメソッド呼び出しをクライアントに提供することこそがサーバーの目的でもあるわけです。残念ながら上記のようにクラスを定義した場合は、クライアントはサーバーの機能を利用できるようになりません。理由は、先にも述べたようにCOMというものが通信であり、クライアントとサーバーが別々のファイルに存在しているからです。サーバーはクライアントに対してクラスを予め公開しておかなければなりません。このようにクラスを公開してしまうと、クライアントのコードがクラスの実装に強く依存するという問題が発生します。これはクライアントのコードを再コンパイルすることによって初めて変化されるものです。実行する環境によって正常に動作しないことが予測されます。した問題を解決するべく、COMではサーバーのクラスをクライアントに公開するようにはなっていません。それをクライアントに公開するようにしているのです。サーバーはクラスのメンバを自由に変更できるようになります。このような方法は、インターフェースと実装の分離と呼ばれることがあります。インターフェースの原則は、一切のメンバを持たないことと、メソッドを純粋仮想関数として定義することです。メンバを公開してしまうと、クライアントがクラスの実装に依存してしまうため、これは避けなければなりません。サーバーの機能を利用できるようなメソッドを含んでおく必要があります。0;}インターフェースのメソッドを仮想関数ではなく、純粋仮想関数として定義していることには大きな意味があります。インターフェースがメソッドの実装を持つことは完全になくなります。これで何が起きるかというと、このインターフェースを他のクラスが再利用できるという利点が生じます。独自のインターフェースを定義して継承する代わりに、既存のインターフェースを継承することができます。第2に、純粋仮想関数として定義すると、メソッド呼び出しにおけるバイナリコードがコンパイラ依存でなくなるという利点が生じます。単純なポインタアクセスということもあり、生成されるコードがコンパイラによって変化するようなことはありません。両者は問題なく通信できるということになります。クラスはインターフェースを継承していなければなりません。クラスはメソッドをオーバーライドすることになります。クライアントが呼び出したメソッドが実は存在しないという自体を防ぎます。次に、インターフェースを継承したクラスの定義を示します。これはIFileControlを継承したことによるものです。それはこのメソッドがCMyServerの中で必要になるものだからです。アクセス修飾子もprivateで構いません。話を整理すると、サーバーは自身のデータを表すクラスを定義したいわけです。インターフェースと実装を分離することにしました。それを通じてクラスの機能を利用してもらうようにしたわけです。してできあがったインターフェースベースの通信が、COMということになります。これはあくまでCOMの一部分を取り上げているに過ぎません。通信の手段としてCOMを選択する理由というものが見えてきません。次に、COMの設計目標を示します。COMは、オブジェクトの実装をクライアントから隠蔽する。これにより、オブジェクトの実装が変化してもクライアントに再コンパイルを要求しない。COMは、クライアントが使用するコンパイラやプログラミング言語を問わない。どのプログラミング言語からでもオブジェクトを利用することができる。COMは、オブジェクトがどこに存在するかをクライアントに意識させない。同じようなコードでオブジェクトを利用することができる。COMは、様々なオブジェクトを統一的な方法で扱える。どのクライアントでもオブジェクトの使い方が理解できる。1番目と2番目の項については、今回述べた通りです。3番目の項については、別の節で詳しく取り上げる予定です。これだけでは少し分かりにくいので、ウインドウメッセージを例に考えてみましょう。片方のプロセスが相手側プロセスを終了させたくなったとします。そこで、次のようなコードを実行することになりました。プロセスの終了を促す独自のメッセージを定義する。その独自のメッセージを相手プロセスのウインドウに送信する。0);この実装は一見、何も問題のないように思えますが、実際には大きな無駄が含まれています。それを無視して独自のメッセージを定義しているという点です。両者が既に理解しているWM_CLOSEを使用するのが最善であると言えます。このような既知の情報というのは、COMではインターフェースという形で大量に定義されています。汎用性が高くなります。