1

タイプとInputTypeタイプの2つのシーケンスを生成するシーケンスを処理する必要があるとします。OutputTypeErrorType

基本的な実装は次のとおりです。

class SeqProcessor {
  private IEnumerable<ErrorType> errorTypes;

  public SeqProcessor()
  {
    this.errorTypes = Enumerable.Empty<ErrorType>;
  }

  public IEnumerable<ErrorType> Errors
  {
    get { return this.errors; } 
  }

  public IEnumerable<OutputType> ProcessItems(IEnumerable<InputType> inputTypes)
  {
     yield return new OutputType();
     if (err) this.errorTypes = this.errorTypes.Concat(new ErrorType());
     yield return new OutputType();
     yield return new OutputType();
     if (err) this.errorTypes = this.errorTypes.Concat(new ErrorType());
     // ...
     yield break;
  }
}

たとえば、次の2つの選択肢があります。

  • IProductとの間OutputTypeで共通のインターフェース（例）を使用し、 returnErrorTypeを許可します（ Linqを使用して区別するよりも）。ProcessItemsIEnumerable<IProduct>

  • ErrorTypecalledのサブクラスを定義し、NoErrorタプルをProcessItems返しますIEnumerable<Tuple<OutputType, ErrorType>>（エラーNoErrorがない場合は、タプルで使用されます）。

編集：

ErrorTypeとは意味的に異なるためOutputType、これらのタイプを混在させると、単一責任原則に違反する可能性があります。デリゲートの使用は、許容できる代替設計になりますか？

class SeqProcessor {
  public IEnumerable<OutputType> ProcessItems(
    IEnumerable<InputType> inputTypes,
    Action<ErrorType> onError)
  {
    yield return new OutputType();
    // ...
    onError(new ErrorType());
  }
}

そのような場合、どのアプローチを使用しますか？

4

2 に答える 2

2

2番目のアプローチは、NoErrorインスタンスがNoErrorの特殊化であることを示唆しています。これが実際に当てはまることはめったにありません。2つの間で共有される機能が小さい可能性が高く、最初のアプローチが優れています。

于 2013-03-13T13:07:31.083 に答える
1

正確に何を達成したいかに応じて、ここに複数の可能な解決策があります。

  1. 元の実装を維持します（ここで置き換えprivate IEnumerable<ErrorType> errorTypesますが、エラーが属するアイテムを判別できるもの）。このコンテキストでは、発生しているエラーは、実際の結果から分離されているため、警告の重要性があります（これが、名前も好む理由です）。Warning

  2. 両方の結果タイプ（つまり、出力とエラー）に共通のインターフェースを使用することは、結果のリストを使用する他の関数が実際にエラー出力を利用できる場合にのみ意味があります。これがあなたの意図したものではないかと思いますが、私見ですが、これは有効な設計上の選択です。

  3. Pieterが指摘したように、のサブクラスを持つことNoErrorはErrorType本当に厄介です。ただし、より良い解決策は、型とResultTypeのベースとして使用することです。そうすれば、あなたは本当に基本クラスの専門性を持っています。それでも、エラーが発生した場合に出力に含まれるのではないかと思います。元の要素？処理されたが無効な要素？ヌル？達成したいことによっては、これは合理的かもしれませんが、与えられた情報からこれを判断するのは困難であり、正直なところ、それがあなたが望んでいることではないかと思います。NoErrorError

  4. OnError柔軟性が高いため、多くの状況でこれを使用することをお勧めします。ただし、そのような場合でも、結果の対応するエントリがどうなるかを考える必要があります。nullイムホ、どちらかまたはいずれかの特別な値の扱いを避けるために、単にそれを除外するのがおそらく最良の選択でしょう。

全体OnErrorとして、追加情報が他の言及されたアプローチの1つにあなたを駆り立てるかもしれないとしても、アプローチは最も有望であるように思われます。

于 2013-03-18T13:19:34.300 に答える