2

私は多くの異なるストリーム（異なるフォーマット）からのデータを解析/処理し、データの異なるソースの数は私のシステムで増え続けています。ソースを指定する構成ファイルに基づいて、次のような要求された適切なパーサー/プロセッサーのペア（小さな共通インターフェースに従う）を提供するファクトリクラスがあります。

static Foo* FooFactory::createFoo(source c, /*couple flags*/)
{
    switch (c)
    {
        case SOURCE_A:
        {
         //3 or 4 lines to put together a parser for A, and something to process stuff    from the parser
             return new FooA(/*args*/);
        }
        break;
        //too many more cases which has started to worry me
        default:
            return NULL;
    };
}

問題は、ソースの数が増えるにつれて、2つの問題に直面していることです。まず、ビルドするときに、FooA, FooB, FooC, FooD, FooE...関連するすべてのコードを取得していることに気付きます。たとえ、要求するだけのバイナリをビルドすることにしか興味がなかったとしても、FooA言うことができます。それで、それをモジュール化する方法について。二次的な問題は、今の場合SOURCE_A、私は戻ってきますがFooA、興味があるSOURCE_Aが、それを解析するさまざまな方法があり、おそらくプラグアンドプレイの機能を備えている場合はどうFooA_simpleなりますか？FooA_careful

何らかの理由で-u、バイナリを構築するときのリンカーのオプションが頭に浮かびました...それはどういうわけか私にプラグアンドプレイの概念を示唆していますが、問題への良いアプローチが何であるかはわかりません。

4

2 に答える 2

1

ファクトリインターフェイスを作成し、そのファクトリのサブタイプ間でロジックを分割するだけです。したがって、libFooAにはサブファクトリ（タイプ/インスタンス）があり、libFooBには別のサブファクトリがある可能性があります。次に、特定のシナリオ/プログラムでサポートするサブファクトリ/ライブラリに応じて、複合ファクトリを簡単に作成できます。次に、工場をさらに細分化することができます。コンポジットタイプのファクトリ列挙子を作成して、そのスイッチロジックをすべて廃止することもできます。次に、libFooAファクトリインスタンスに、その上位レベルで注意モードまたは単純モードを有効にするように指示する場合があります。したがって、FooFactoryインスタンスとサブタイプのグラフは簡単に変更でき、クラス構造はツリーのようになります。ライブラリは、依存関係を最小限に抑えるためにアプローチする1つの方法ですが、特殊なサブファクトリを分割するためのより論理的な方法がある場合があります。

于 2012-11-07T05:31:19.693 に答える
0

FooA、FooB ...のインポートを回避できるかどうかはわかりません。いつでも、それらのいずれかがインスタンス化される可能性があるためです。モジュール化に関しては、switchステートメント内で呼び出されるヘルパー関数を作成することをお勧めします。

于 2012-11-07T04:53:30.647 に答える