Pour moi Concat
comme méthode d'extension n'est pas très élégante dans mon code lorsque j'ai plusieurs grandes séquences à concaténer. Il s'agit simplement d'un problème d'indentation/de formatage du code et de quelque chose de très personnel.
Bien sûr, ça a l'air bien comme ça :
var list = list1.Concat(list2).Concat(list3);
Ce n'est pas si facile à lire quand cela se présente comme suit :
var list = list1.Select(x = > x)
.Concat(list2.Where(x => true)
.Concat(list3.OrderBy(x => x));
Ou quand il ressemble à.. :
return Normalize(list1, a, b)
.Concat(Normalize(list2, b, c))
.Concat(Normalize(list3, c, d));
ou tout autre format préféré. Les choses empirent avec des concaténations plus complexes. La raison de mon en quelque sorte La dissonance cognitive avec le style ci-dessus est que la première séquence se situe en dehors de l'espace de travail. Concat
alors que les séquences suivantes se trouvent à l'intérieur. Je préfère appeler la méthode statique Concat
directement et non le style d'extension :
var list = Enumerable.Concat(list1.Select(x => x),
list2.Where(x => true));
Pour un plus grand nombre de séquences concaténées, j'utilise la même méthode statique que dans l'OP :
public static IEnumerable<T> Concat<T>(params IEnumerable<T>[] sequences)
{
return sequences.SelectMany(x => x);
}
Je peux donc écrire :
return EnumerableEx.Concat
(
list1.Select(x = > x),
list2.Where(x => true),
list3.OrderBy(x => x)
);
Il a l'air mieux. Le nom de classe supplémentaire, autrement redondant, que je dois écrire n'est pas un problème pour moi, étant donné que mes séquences ont l'air plus propres avec l'élément Concat
appel. C'est moins un problème en C# 6 . Vous pouvez simplement écrire :
return Concat(list1.Select(x = > x),
list2.Where(x => true),
list3.OrderBy(x => x));
On aurait aimé avoir des opérateurs de concaténation de listes en C#, quelque chose comme :
list1 @ list2 // F#
list1 ++ list2 // Scala
C'est beaucoup plus propre.