IEnumerable "State Machines" erkennen

Ich habe gerade einen interessanten Artikel mit dem Titel Getting too cute with c # yield return gelesen

Ich habe mich gefragt, wie ich am besten feststellen kann, ob es sich bei IEnumerable um eine tatsächliche Auflistung von Enumerables handelt oder ob es sich um einen mit dem Schlüsselwort yield generierten Zustandsautomaten handelt.

Beispielsweise könnten Sie DoubleXValue (aus dem Artikel) in etwas ändern, wie:

private void DoubleXValue(IEnumerable<Point> points)
{
    if(points is List<Point>)
      foreach (var point in points)
        point.X *= 2;
    else throw YouCantDoThatException();
}

Frage 1) Gibt es einen besseren Weg, dies zu tun?

Frage 2) Sollte ich mir darüber Gedanken machen, wenn ich eine API erstelle?

Wie ich es verstehe, scheint Ihre Frage auf einer falschen Prämisse zu beruhen. Lassen Sie mich sehen, ob ich die Argumentation rekonstruieren kann:

• Der verlinkte Artikel beschreibt, wie sich automatisch generierte Sequenzen "träge" verhalten und wie dies zu einem kontraintuitiven Ergebnis führen kann.
• Daher kann ich feststellen, ob eine bestimmte Instanz von IEnumerable dieses verzögerte Verhalten aufweisen wird, indem ich überprüfe, ob es automatisch generiert wird.
• Wie mache ich das?

Das Problem ist, dass die zweite Prämisse falsch ist. Selbst wenn Sie feststellen könnten, ob eine bestimmte IEnumerable das Ergebnis einer Iteratorblocktransformation ist (und ja, es gibt Möglichkeiten, dies zu tun), würde dies nicht helfen, da die Annahme falsch ist. Lassen Sie uns veranschaulichen, warum.

class M { public int P { get; set; } }
class C
{
  public static IEnumerable<M> S1()
  {
    for (int i = 0; i < 3; ++i) 
      yield return new M { P = i };
  }

  private static M[] ems = new M[] 
  { new M { P = 0 }, new M { P = 1 }, new M { P = 2 } };
  public static IEnumerable<M> S2()
  {
    for (int i = 0; i < 3; ++i)
      yield return ems[i];
  }

  public static IEnumerable<M> S3()
  {
    return new M[] 
    { new M { P = 0 }, new M { P = 1 }, new M { P = 2 } };
  }

  private class X : IEnumerable<M>
  {
    public IEnumerator<X> GetEnumerator()
    {
      return new XEnum();
    }
    // Omitted: non generic version
    private class XEnum : IEnumerator<X>
    {
      int i = 0;
      M current;
      public bool MoveNext()
      {
        current = new M() { P = i; }
        i += 1;
        return true;
      }
      public M Current { get { return current; } }
      // Omitted: other stuff.
    }
  }

  public static IEnumerable<M> S4()
  {
    return new X();
  }

  public static void Add100(IEnumerable<M> items)
  {
    foreach(M item in items) item.P += 100;
  }
}

Okay, wir haben vier Methoden. S1 und S2 sind automatisch generierte Sequenzen; S3 und S4 sind manuell erzeugte Sequenzen. Nehmen wir nun an, wir haben:

var items = C.Sn(); // S1, S2, S3, S4
S.Add100(items);
Console.WriteLine(items.First().P);

Das Ergebnis für S1 und S4 ist 0; Jedes Mal, wenn Sie die Sequenz aufzählen, erhalten Sie einen neuen Verweis auf ein erstelltes M. Das Ergebnis für S2 und S3 ist 100; Jedes Mal, wenn Sie die Sequenz aufzählen, erhalten Sie denselben Verweis auf M, den Sie beim letzten Mal erhalten haben. Ob der Sequenzcode automatisch generiert wird oder nicht, ist orthogonal zur Frage, ob die aufgezählten Objekte eine referenzielle Identität haben oder nicht. Diese beiden Eigenschaften - automatische Generierung und referenzielle Identität - haben eigentlich nichts miteinander zu tun. Der Artikel, den Sie verlinkt haben, widerspricht ihnen etwas.

Sofern ein Sequenzanbieter nicht dokumentiert ist, dass er Objekte mit referentieller Identität immer anbietet , ist es nicht ratsam , dies anzunehmen.

Ich denke, das Schlüsselkonzept ist, dass Sie jede IEnumerable<T>Sammlung als unveränderlich behandeln sollten : Sie sollten die Objekte daraus nicht ändern, Sie sollten eine neue Sammlung mit neuen Objekten erstellen:

private IEnumerable<Point> DoubleXValue(IEnumerable<Point> points)
{
    foreach (var point in points)
        yield return new Point(point.X * 2, point.Y);
}

(Oder schreiben Sie dasselbe mit LINQ genauer Select().)

Wenn Sie die Elemente in der Auflistung tatsächlich ändern möchten, verwenden Sie nicht IEnumerable<T>, verwenden Sie IList<T>(oder möglicherweise, IReadOnlyList<T>wenn Sie die Auflistung selbst nicht ändern möchten, nur die Elemente in der Auflistung, und Sie sind auf .Net 4.5):

private void DoubleXValue(IList<Point> points)
{
    foreach (var point in points)
        point.X *= 2;
}

Auf diese Weise IEnumerable<T>schlägt die Kompilierung fehl , wenn jemand versucht, Ihre Methode mit zu verwenden .

Ich persönlich denke, das in diesem Artikel hervorgehobene Problem rührt von der übermäßigen Nutzung der IEnumerableBenutzeroberfläche durch viele C # -Entwickler in diesen Tagen her. Es scheint der Standardtyp geworden zu sein, wenn Sie eine Sammlung von Objekten benötigen - aber es gibt eine Menge Informationen, IEnumerabledie Ihnen einfach nicht sagen ... Entscheidend ist, ob sie erneut bestätigt wurden oder nicht *.

Wenn Sie feststellen, dass Sie feststellen müssen , ob a IEnumerablewirklich ein IEnumerableoder etwas anderes ist, ist die Abstraktion durchgesickert und Sie befinden sich wahrscheinlich in einer Situation, in der Ihr Parametertyp etwas zu locker ist. Wenn Sie die zusätzlichen Informationen benötigen, die IEnumerableallein nicht zur Verfügung stehen, machen Sie diese Anforderung explizit, indem Sie eine der anderen Schnittstellen wie ICollectionoder auswählen IList.

Edit für die Downvoter Bitte gehen Sie zurück und lesen Sie die Frage sorgfältig. Das OP fragt nach einer Möglichkeit, um sicherzustellen, dass IEnumerableInstanzen materialisiert wurden, bevor sie an seine API-Methode übergeben werden. Meine Antwort beantwortet diese Frage. Es gibt ein größeres Problem in Bezug auf die ordnungsgemäße Verwendung IEnumerable, und die Erwartungen an den vom OP eingefügten Code beruhen sicherlich auf einem Missverständnis dieses umfassenderen Problems, aber das OP fragte nicht, wie es richtig verwendet IEnumerableoder wie mit unveränderlichen Typen gearbeitet werden soll . Es ist nicht fair, mich dafür zu beleidigen, dass ich eine nicht gestellte Frage nicht beantwortet habe.

* Ich verwende den Begriff reify, andere verwenden stabilizeoder materialize. Ich glaube nicht, dass die Community gerade eine gemeinsame Konvention verabschiedet hat.