Réimplémentation de LINQ to Objects : Partie 6 - « Repeat »

Jon Skeet

Traducteur

Holty Samba SOW

Ce tutoriel est la sixième partie de la série intitulée Edulinq. Dans cette partie, Jon Skeet nous propose la réimplémentation de l'opérateur « Repeat » de Linq to Objects.

Partie précédente : Réimplémentation de LINQ to Objects : Partie 5 - « Empty »

Partie suivante : Réimplémentation de LINQ to Objects : Partie 7 - « Count et LongCount »

Commentez cet article : Commentez

- Titre : Réimplémentation de LINQ to Objects : Partie 6 - « Repeat »

- Auteur : Jon Skeet

- Traducteur : Holty Samba SOW

- Parution : 6 juillet 2013

- Mise à jour : 6 juillet 2013

- Public visé :

- Licence : Le contenu de cet article est rédigé par Jon Skeet et est mis à disposition selon les termes de la Licence Creative Commons Attribution 3.0 non transposé. Les logos Developpez.com, en-tête, pied de page, css, et look & feel de l'article sont Copyright ® 2013 Developpez.com.

Sommaire

- Qu'est-ce que c'est ?

- Qu'allons-nous tester ?

- Voyons l'implémentation !

- Conclusion

- Remerciements

Qu'est-ce que c'est ?

« Repeat» est méthode statique générique, qui n'est pas une méthode d'extension, avec une seule surcharge :

public static IEnumerable<TResult> Repeat<TResult>(
TResult element,
int count)

Elle retourne simplement une séquence contenant uniquement l'élément spécifié répété «count» fois. La seule validation de l'argument est que «count» ne doit pas être négatif.

Qu'allons-nous tester ?

Il n'y a vraiment pas beaucoup de choses à tester ici. J'ai pensé à quatre scénarios différents :

- une séquence simple « répétition d'une chaîne trois fois » ;

- une séquence vide « répétition d'une chaîne zéro fois » ;

- une séquence contenant des valeurs null (juste pour prouver qu'un « élément » peut être null) ;

- un comptage négatif pour prouver que la validation de l'argument se déclenche et cela très tôt.

J'ai bien peur que rien de cela ne soit vraiment passionnant.

Voyons l'implémentation !

Juste une chose qu'on pourrait être amené à mal faire ici, c'est la validation de l'argument directement dans un bloc itérateur… et nous avons déjà mis en place le pattern « méthode de fractionnement » tant de fois que nous n'allions pas tomber dans ce piège. Ainsi voici le code écrit sans aucune gloire :

public static IEnumerable<TResult> Repeat<TResult>(TResult element, int count)
{
if (count < 0)
{
throw new ArgumentOutOfRangeException("count");
}
return RepeatImpl(element, count);
}

private static IEnumerable<TResult> RepeatImpl<TResult>(TResult element, int count)
{
for (int i = 0; i < count; i++)
{
yield return element;
}
}

C'est tout. Hum, des points intéressants à noter… Aucun.

Conclusion

Il n'y a aucune raison à faire traîner les choses. Ce serait trop. Prochaine étape, Count et LongCount qui ont en fait quelques points intéressants.

Remerciements

Je tiens ici à remercier Jon Skeet de m'avoir autorisé à traduire son article Reimplementing LINQ to Objects: Part 6 - Repeat.

Je remercie rv26t pour sa relecture technique et ses propositions.

Je remercie également zoom61 pour sa relecture orthographique et ses propositions.