2

私はシステムの新しいコンポーネントを設計しており、DIに関するさまざまなガイドラインに従おうとしているので、分離、モックなどの点で見返りが得られます。

したがって、次のコンポーネントがあります（抽象化として示されています）。

  • Fetcher-特定のデータソースからデータをフェッチするIFetcherをサポートします。IDataSourceを返します。
  • Builder-IDataSourceから構造を構築するIBuilderをサポートします。

これらを「Performer」（より良い名前が必要な場合）コンポーネントにまとめたいと思います。これにより、次のようになります。

IDataSet Performer.Perform(IFetcher fetcher, IBuilder builder)
{
  IDataSource ds = fetcher.Fetch();
  return builder.BuildDataSet(ds);
}

依存性注入とLoDのガイドラインに準拠するために（とにかく理解している限り）、IFetcherコンポーネントとIBuilderコンポーネントの両方をに渡します。

私の質問-これは許容できる設計のように聞こえますか？同僚との会話は「ええ、いいですね」の線に沿っていますが、パフォーマークラスによるカプセル化を100％確信しているわけではありません。

私の見方では、パフォーマーは、いくつかの異なるコンポーネントを接着する複合コントロールであり、許容できるはずです。唯一の疑問符は、「Performer Factory」が必要かどうかですが、実際のコンポーネント（IFetcherとIBuilder）がモックされる可能性があることを考えると、これはやり過ぎのようです。

どんな考えでもありがたいです、ありがとう。

4

1 に答える 1

1

DIの観点から、私が変更するのは、実行者コンストラクターでフェッチャーとビルダーを取得することだけです。すなわち

public class Performer { 

    private IFetcher fetcher; 
    private IBuilder builder;        

    public Performer(IFetcher fetcher, IBuilder builder) {
       this.fetcher = fetcher;
       this.builder = builder;
    }

    public IDataSet Perform(DataSource ds){
       IDataSource ds = fetcher.Fetch();
       return builder.BuildDataSet(ds); 
    }
}

そして、DIフレームワークを使用します。いいえ、ファクトリメソッドは必要ないと思います。必要なときにIPerformerを呼び出すだけで、DIフレームワークがIPerformerを構築します。

于 2008-12-04T12:08:27.727 に答える