1

私たちのコードベースには多くの COM オブジェクトがあるため、通常は次のようになります。

//this is the IDL-generated IGetTime interface header
#include "gettime.h"

//our COM class implementation of IGetTime
class CGetTime : public IGetTime
{
  public:
    CGetTime(CGetTimeCF &factory,...); //COM-specific constructor params
    /* IUnknown */
    STDMETHODIMP QueryInterface(REFIID riid, LPVOID FAR * ppv);
    STDMETHODIMP_(ULONG) AddRef();
    STDMETHODIMP_(ULONG) Release();

    /* IGetTime */
    STDMETHODIMP GetTheTime(); //
};

コンストラクターと他のいくつかの設定方法により、このクラスは COM を介してのみ簡単に使用できます...オブジェクトを作成する方法をハックできますが、不安定になる傾向があります。多くの場合、クラスの実際の機能はCOMなしで使用できる可能性があります...そして、これができれば、これもより簡単にテストできますnew CGetTime();

私はパターンとしてこのようなものを持つことについて疑問に思いました:

class CGetTimeBase
{
 public:
  STDMETHODIMP GetTheTime();
};

class CGetTime : public IGetTime, public CGetTimeBase
{
...
};

これは良いアプローチですか、それともコア機能を提供する「プレーン C++」クラスと、COM を実行する COM クラスを使用するより良い方法はありますか? 記述するコードの量を最小限に抑えるために、ラッパー メソッドを導入したくないと思いますが、COM 以外のクラスに実際の実装メソッドがあるため、COM クラスに自動的に存在します。

考え？};

4

1 に答える 1

5

私が働いている場所では、いくつかの理由からコア クラスをコアC++クラスから分離することにしました。COM

  1. これは保守が容易です。あまり知識COMのない人は、コア クラスの作成に集中できます。知識がある人COMは、基礎となる実装を気にすることなく、コア クラスを安全にラップできます。

  2. コードの再利用性。これは必須ではないかもしれませんが、コア クラスはコア クラスから切り離されているため、必要のないプロジェクトでCOM直接使用する場合があります。C++COM

  3. コアテスト。ロジックがインターフェースから分離されているため、最小限のテストに簡単に進むことができます。「リークはどこにあるのか? コア ロジックの正当なリークなのか、それとも関連するものなのCOMか?」と疑問に思う必要はもうありません。コア クラスは、独立して効率的にテストできます。

これにより、ファイル数とコンパイル時間の両方が増加しますが、それだけの価値があると思います。

于 2010-06-24T09:40:55.410 に答える