3

お客様から次のようなコードを受け取りました。

public class Thing
{
    // custom functionality for Thing...
}

public class Things : IEnumerable
{
    Thing[] things;
    internal int Count { get { return things.Length; } }

    public Thing this[int i] { get { return this.things[i]; } }

    public IEnumerator GetEnumerator() { return new ThingEnumerator(this); }

    // custom functionality for Things...
}

public class ThingEnumerator : IEnumerator
{
    int i;
    readonly int count;
    Things container;

    public ThingEnumerator(Things container)
    {
        i = -1;
        count = container.Count;
        this.container = container;
    }

    public object Current { get { return this.container[i]; } }
    public bool MoveNext() { return ++i < count; }
    public void Reset() { i = -1; }
}

私が疑問に思っているのは、クラスを取り除き、呼び出しを単に に委譲する実装にThingEnumerator置き換えたほうがよかったのでしょうか? そのようです：Things.GetEnumeratorarrayGetEnumerator

public IEnumerator GetEnumerator() { return things.GetEnumerator(); }

コードをそのままにしておく利点はありますか? (私が気付いたもう 1 つのことは、既存のコードを に置き換えることで改善できることIEnumeratorですIEnumerator<Thing>。)

4

5 に答える 5

3

IEnumerableジェネリックでは、実装と自分自身の価値はほとんどありませんIEnumerator。

これらを削除すると、クラスがジェネリック コレクションに置き換えられ、維持するコードがはるかに少なくなり、機能することがわかっているコードを使用できるという利点があります。

于 2013-05-13T10:25:46.363 に答える
2

System.Collections.CollectionBaseあなたが持っているコードは、.NETジェネリックが利用可能になる前に、.NET 1.0/1.1用に書かれたコードのように見えます.コレクションの実行時型に。ただし、値型を使用していて、ボックス化/ボックス化解除がパフォーマンスの制限要因でない限り、 I は から継承され、 orCollectionBaseを再定義する必要はありません。GetEnumerator()Count

ただし、次の 2 つの方法のいずれかをお勧めします。

  1. カスタム コレクションにカスタム機能を持たせる必要がある場合は、コレクションを派生させSystem.Collections.ObjectModel.Collection<Thing>ます。コレクション内の項目の挿入、置換、および削除を制御するために必要なすべてのフックが提供されます。

  2. 列挙する必要があるものだけが実際に必要な場合は、 にIList<Thing>裏打ちされた標準を返しList<Thing>ます。

于 2013-05-13T10:33:30.480 に答える
1

配列列挙子は、カスタム列挙子とほとんど同じことを行うので、配列の列挙子を直接返すこともできます。
この場合、配列列挙子もより多くのエラーチェックを実行し、あなたが述べたように単純であるため、それを行うことをお勧めします。

于 2013-05-13T10:31:05.970 に答える
1

カスタム列挙子で真のカスタム (ある種の検証など) を行っていない限り、これを行う理由はまったくありません。

一般に、そうしない明確な理由がない限り、標準ライブラリで利用可能なものを使用してください。コードの個々の単位として、より適切にテストされ、より多くの時間が費やされる可能性が高いため、費やす余裕があり、なぜホイールを再作成するのですか?

このような場合、コードは既に存在しますが、十分にテストする時間があれば、コードを置き換える方がよい場合があります。(まともな単体テストのカバレッジがあれば、それは簡単です。)

メンテナンスのオーバーヘッドを削減し、潜在的な潜在的なバグの原因を取り除き、コードを見つけたよりもクリーンなままにします。ボブおじさんは誇りに思うでしょう。

于 2013-05-13T10:27:32.427 に答える