3

要するに、プラグインがメインアプリケーションのオブジェクトを置き換えることができるように、ファクトリー+プラグインメカニズムを設計および実装する最良の方法は何ですか.

アプリケーションを構築するためのコード ベースがあります。コード ベースは、アプリケーションの 70 ～ 95% で問題ありません。つまり、新しいアプリケーションごとに、デフォルトの動作の 5 ～ 30% を変更する必要があります (新しい機能の追加、デフォルト ロジックの変更、GUI の追加など)。

実装はプラグイン ベースです。コード ベースは EXE と DLL に組み込まれており、メインの EXE が実行されているときに、必要な機能を追加する DLL をロードします。

現在、各プラグインは次の機能を公開しています。

PluginInterface* PluginInit()
{
    return new MyCustomizedPluginInterface();
}

PluginInterface は次のように定義されています。

class PluginInterface {
public:
    virtual SomeClass1* customizedSomeClass1() = 0;
    virtual SomeClass2* customizedSomeClass2() = 0;
};

また、 SomeClass1/SomeClass2 にはいくつかのデフォルトの動作がありますが、プラグインによってオーバーライドおよび変更できます。

現在の実装では、新しいカスタマイズされたクラスを追加することが難しくなっています。メイン アプリケーションのすべてのクラスをプラグインから置き換えたいので、オブジェクト ファクトリを使用することは理にかなっています。

私が知っている 1 つの SDK では、次の手法が使用されています。

PluginInterface* PluginInit(GodObject* godObject)
{
    FactoryForSomeClasses* factoryForSomeClasses = 
        godObject->factoryForSomeClasses();
    factoryForSomeClasses->setSomeClass1Creator( MyCustomizedSomeClass1::create); // create is a static creator function.
    factoryForSomeClasses->setSomeClass2Creator( MyCustomizedSomeClass2::create);
}

このアプローチに代わるものがあるのだろうか。

今説明したようなプラグイン システム/ファクトリをどのように設計および実装することをお勧めしますか?

4

2 に答える 2

2

ドッブ博士の記事で、この正確な問題について論じた記事がありました。問題の記事へのリンクはこちらです。

余談ですが、プロジェクトへのプラグインにはストレートな C インターフェースを使用することをお勧めします。そうすれば、ほとんどすべての言語で記述されたコードを最小限の手間でフレームワークにリンクできます。C++ は素晴らしいものですが、Java や Python の世界に存在する驚異的なフレームワークなど、C++ に存在するもの以上のものを活用できることは、長期的には有益であることが証明される可能性があります。

于 2008-11-22T17:37:08.563 に答える
1

プラグイン フレームワークの CodeProject の例を見ましたか? https://secure.codeproject.com/KB/DLL/plugin.aspx http://www.codeproject.com/KB/library/dynobj.aspx

于 2008-11-22T14:16:44.850 に答える