3

ストラテジーとアブストラクトファクトリのデザインパターンについては知っていますが、現在の問題は解決していません。

非常に基本的なGUIを提供するC++ライブラリを作成しています。ただし、コンパイル時に、実際にGUIをレンダリングするために使用するGUIライブラリ（QtやFLTKなど）をユーザーが選択できるようにしたいと思います。ただし、ユーザーは私のライブラリのメソッドについてのみ知っている必要があります。

QtバックエンドまたはFLTKバックエンドのいずれかを使用して、変更なしで同じコードをコンパイルできるはずです。

私は次のようなことを考えました：

class A
{
  // do things that are not specific to QT or FLTK here as there are many 
  // methods I will need independent of the backend
}

class QT_A : public A
{
  // Implement the actual creation of a window, display of a widget here using Qt
}

class FLTK_A : public A
{
  // Implement the actual creation of a window, display of a widget here using FLTK
}

QT_A問題は、ユーザーにまたはについて知られたくないということですFLTK_A。ユーザー（開発者）はただ対処する必要がありAます。また、ライブラリがQtとFLTKの両方に依存することを望まないため、両方のバリアントを同時に持つことはできません。コンパイル時に選択された方だけです。

4

3 に答える 3

4

Pimplイディオムは代替手段かもしれません。これにより、フレームワークに依存するメンバーなしで共通のインターフェースを作成できます。

class A
{
  struct impl;
  std::unique_ptr<impl> pimpl; // or scoped_ptr/auto_ptr on non-C++11
public:
  A();
  ~A();
 void do_sth();
};

次に、ソースファイルは、バックエンドに応じてimplのさまざまな実装を提供できます。

#ifdef QT
struct A::impl : QWidget { // Make it polymorphic, if you need
  QImage img;
  QString data;
};

void A::do_sth()
{
  impl->make_it(); // full access to the Qt things
}

A::A()
  : pimpl(new ...)
{
}

A::~A() {} // no need for delete thanks the smart pointer

#endif
于 2013-01-23T17:52:07.517 に答える
4

1つのオプションは、別の回答で説明されているPimplイディオムです。

もう1つのオプションは、インターフェイスクラスへのポインタを返すファクトリです。

std::unique_ptr<A> make_A()
{
#if defined(USING_QT)
    return std::unique_ptr<A>(new QT_A(...));
#elif defined(USING_FLTK)
    return std::unique_ptr<A>(new FLTK_A(...));
#else
    #error "No GUI library chosen"
#endif
}
于 2013-01-23T17:59:17.437 に答える
3

派手なパターンは必要ありません。

配布します

  1. Aのヘッダー。
  2. A、、、QT_Aおよびmake_A関数を含むライブラリ。
  3. を含む別のライブラリA、FLTK_Aおよびmake_A関数の別の実装。

ユーザーはいずれかのライブラリにリンクします。

于 2013-01-23T18:12:12.590 に答える