Wykrywanie niezliczonych „automatów stanowych”

Właśnie przeczytałem interesujący artykuł zatytułowany Robi się zbyt słodki z zyskiem c #

Zastanawiałem się, jaki jest najlepszy sposób na wykrycie, czy IEnumerable jest faktyczną kolekcją, którą można wyliczyć, czy też jest maszyną stanu wygenerowaną za pomocą słowa kluczowego fed.

Na przykład możesz zmodyfikować DoubleXValue (z artykułu) na coś takiego:

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

Pytanie 1) Czy jest na to lepszy sposób?

Pytanie 2) Czy powinienem się tym martwić podczas tworzenia interfejsu API?

Twoje pytanie, jak rozumiem, wydaje się opierać na niewłaściwym założeniu. Zobaczmy, czy mogę zrekonstruować rozumowanie:

• Artykuł z linkami opisuje, w jaki sposób automatycznie generowane sekwencje wykazują zachowanie „leniwe” i pokazuje, jak może to prowadzić do sprzecznych z intuicją wyników.
• Dlatego mogę wykryć, czy dana instancja IEnumerable będzie wykazywać to leniwe zachowanie, sprawdzając, czy jest ona generowana automatycznie.
• Jak mogę to zrobić?

Problem polega na tym, że druga przesłanka jest fałszywa. Nawet gdybyś mógł wykryć, czy dany IEnumerable był wynikiem transformacji bloku iteratora (i tak, istnieją sposoby, aby to zrobić), nie pomogłoby to, ponieważ założenie jest błędne. Zilustrujmy dlaczego.

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;
  }
}

W porządku, mamy cztery metody. S1 i S2 są automatycznie generowanymi sekwencjami; S3 i S4 są sekwencjami generowanymi ręcznie. Załóżmy teraz, że mamy:

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

Wynik dla S1 i S4 wyniesie 0; za każdym razem, gdy wyliczasz sekwencję, dostajesz nowe odniesienie do utworzonego M. Wynik dla S2 i S3 wyniesie 100; za każdym razem, gdy wyliczasz sekwencję, dostajesz to samo odniesienie do M, które dostałeś ostatni raz. To, czy kod sekwencji jest generowany automatycznie, czy nie, jest prostopadłe do pytania, czy wyliczone obiekty mają tożsamość referencyjną, czy nie. Te dwie właściwości - automatyczne generowanie i tożsamość referencyjna - w rzeczywistości nie mają ze sobą nic wspólnego. Artykuł, który podlinkowałeś, nieco je łączy.

O ile dostawca sekwencji nie jest udokumentowany jako zawsze oferujący obiekty, które mają tożsamość referencyjną , nie należy zakładać, że tak jest.

Myślę, że kluczową koncepcją jest to, że każdą IEnumerable<T>kolekcję należy traktować jako niezmienną : nie należy modyfikować z niej obiektów, należy utworzyć nową kolekcję z nowymi obiektami:

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

(Lub napisz to bardziej zwięźle, używając LINQ Select().)

Jeśli naprawdę chcesz zmodyfikować elementy w kolekcji, nie używaj IEnumerable<T>, nie używaj IList<T>(lub ewentualnie IReadOnlyList<T>jeśli nie chcesz modyfikować samej kolekcji, tylko elementy w niej, a jesteś w .Net 4.5):

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

W ten sposób, jeśli ktoś spróbuje użyć twojej metody IEnumerable<T>, zawiedzie ona podczas kompilacji.

Osobiście uważam, że problem wskazany w tym artykule wynika z nadmiernego używania IEnumerableinterfejsu przez wielu programistów C # w dzisiejszych czasach. Wygląda na to, że stał się domyślnym typem, gdy potrzebujesz kolekcji obiektów - ale jest wiele informacji, które IEnumerablepo prostu nie mówią ci ... co najważniejsze: czy zostało to potwierdzone czy nie *.

Jeśli okaże się, że musisz wykryć, czy an IEnumerablejest naprawdę an, IEnumerableczy czymś innym, abstrakcja wyciekła i prawdopodobnie jesteś w sytuacji, gdy typ parametru jest nieco zbyt luźny. Jeśli potrzebujesz dodatkowych informacji, których IEnumerablesam nie zapewnia, wyraź to wymaganie, wybierając jeden z innych interfejsów, takich jak ICollectionlub IList.

Edytuj dla downvoters Wróć i przeczytaj uważnie pytanie. OP prosi o sposób zagwarantowania, że IEnumerableinstancje zostały zmaterializowane przed przekazaniem ich do jego metody API. Moja odpowiedź dotyczy tego pytania. Istnieje szerszy problem dotyczący właściwego sposobu użycia IEnumerable, a na pewno oczekiwania dotyczące kodu, który wklejono OP, są oparte na nieporozumieniu tego szerszego problemu, ale OP nie zapytał, jak prawidłowo używać IEnumerablelub jak pracować z niezmiennymi typami . Nie jest sprawiedliwe głosować za to, że nie odpowiedziałem na pytanie, które nie zostało postawione.

* Używam tego terminu reify, inni używają stabilizelub materialize. Nie sądzę, aby społeczność przyjęła jeszcze wspólną konwencję.