Détection des «machines d'état» IEnumerable

Je viens de lire un article intéressant intitulé Trop mignon avec le rendement c #

Cela m'a fait me demander quelle est la meilleure façon de détecter si un IEnumerable est une collection énumérable réelle, ou s'il s'agit d'une machine d'état générée avec le mot-clé yield.

Par exemple, vous pouvez modifier DoubleXValue (de l'article) en quelque chose comme:

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

Question 1) Existe-t-il une meilleure façon de procéder?

Question 2) Est-ce quelque chose dont je dois m'inquiéter lors de la création d'une API?

Si je comprends bien, votre question semble reposer sur une prémisse incorrecte. Voyons si je peux reconstruire le raisonnement:

• L'article lié à décrit comment les séquences générées automatiquement présentent un comportement "paresseux" et montre comment cela peut conduire à un résultat contre-intuitif.
• Par conséquent, je peux détecter si une instance donnée de IEnumerable va présenter ce comportement paresseux en vérifiant si elle est générée automatiquement.
• Comment je fais ça?

Le problème est que la deuxième prémisse est fausse. Même si vous pouviez détecter si un IEnumerable donné était le résultat d'une transformation de bloc d'itérateur (et oui, il existe des moyens de le faire), cela ne serait pas utile car l'hypothèse est fausse. Illustrons pourquoi.

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

D'accord, nous avons quatre méthodes. S1 et S2 sont des séquences générées automatiquement; S3 et S4 sont des séquences générées manuellement. Supposons maintenant que nous ayons:

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

Le résultat pour S1 et S4 sera 0; chaque fois que vous énumérez la séquence, vous obtenez une nouvelle référence à un M créé. Le résultat pour S2 et S3 sera 100; chaque fois que vous énumérez la séquence, vous obtenez la même référence à M que vous avez obtenue la dernière fois. Que le code de séquence soit généré automatiquement ou non est orthogonal à la question de savoir si les objets énumérés ont une identité référentielle ou non. Ces deux propriétés - génération automatique et identité référentielle - n'ont en fait rien à voir l'une avec l'autre. L'article auquel vous avez lié les confond un peu.

À moins qu'un fournisseur de séquence ne soit documenté comme offrant toujours des objets ayant une identité référentielle , il est imprudent de supposer qu'il le fait.

Je pense que le concept clé est que vous devez traiter toute IEnumerable<T>collection comme immuable : vous ne devez pas en modifier les objets, vous devez créer une nouvelle collection avec de nouveaux objets:

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

(Ou écrivez le même plus succinctement en utilisant LINQ Select() .)

Si vous voulez vraiment modifier les éléments de la collection, ne pas utiliser IEnumerable<T>, l' utilisation IList<T>(ou peut - être IReadOnlyList<T>si vous ne voulez pas modifier la collection elle - même, seuls les éléments qu'il contient , et vous êtes sur .Net 4.5):

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

De cette façon, si quelqu'un tente d'utiliser votre méthode avec IEnumerable<T>, elle échouera au moment de la compilation.

Personnellement, je pense que le problème mis en évidence dans cet article provient de la surutilisation de l' IEnumerableinterface par de nombreux développeurs C # ces jours-ci. Il semble être devenu le type par défaut lorsque vous avez besoin d'une collection d'objets - mais il y a beaucoup d'informations qui IEnumerablene vous disent tout simplement pas ... de manière cruciale: si oui ou non il a été réifié *.

Si vous trouvez que vous devez détecter si un IEnumerableest vraiment un IEnumerableou quelque chose d'autre, l'abstraction a fui et vous êtes probablement dans une situation où votre type de paramètre est un peu trop lâche. Si vous avez besoin d'informations supplémentaires qui IEnumerableseules ne fournissent pas, expliquez cette exigence en choisissant l'une des autres interfaces telles que ICollectionou IList.

Modifier pour les downvoters Veuillez revenir en arrière et lire attentivement la question. L'OP demande un moyen de s'assurer que les IEnumerableinstances ont été matérialisées avant d'être transmises à sa méthode API. Ma réponse répond à cette question. Il y a un problème plus large concernant la bonne façon d'utiliserIEnumerable , et certainement les attentes du code que l'OP a collé sont basées sur une mauvaise compréhension de ce problème plus large, mais l'OP n'a pas demandé comment utiliser correctement IEnumerable, ou comment travailler avec des types immuables . Ce n'est pas juste de me déprécier de ne pas avoir répondu à une question qui n'a pas été posée.

* J'utilise le terme reify, d'autres utilisent stabilizeou materialize. Je ne pense pas qu'une convention commune ait été adoptée par la communauté pour l'instant.