Une solution plus moderne
À moins que vous n'ayez besoin que la collection interne soit mutable, vous pouvez utiliser l'option System.Collections.Immutable
modifiez votre type de champ pour qu'il devienne une collection immuable, puis exposez-le directement - en supposant que le paquet Foo
elle-même est immuable, bien sûr.
Réponse actualisée pour répondre plus directement à la question
Y a-t-il une raison d'exposer une collection interne comme ReadOnlyCollection plutôt que comme IEnumerable si le code appelant ne fait qu'itérer sur la collection ?
Cela dépend de la confiance que vous accordez au code d'appel. Si vous avez un contrôle total sur tout ce qui appellera ce membre et que vous garantie qu'aucun code n'utilisera jamais :
ICollection<Foo> evil = (ICollection<Foo>) bar.Foos;
evil.Add(...);
alors bien sûr, aucun mal ne sera fait si vous renvoyez directement la collection. J'essaie généralement d'être un peu plus paranoïaque que ça.
De même, comme vous le dites : si seulement vous besoin de IEnumerable<T>
alors pourquoi s'attacher à quelque chose de plus fort ?
Réponse originale
Si vous utilisez .NET 3.5, vous pouvez éviter de faire une copie. y éviter le simple cast en utilisant un simple appel à Skip :
public IEnumerable<Foo> Foos {
get { return foos.Skip(0); }
}
(Il existe de nombreuses autres options pour envelopper de manière triviale - l'avantage de la fonction Skip
par rapport à Select/Where est qu'il n'y a pas de délégué à exécuter inutilement à chaque itération).
Si vous n'utilisez pas .NET 3.5, vous pouvez écrire un wrapper très simple pour faire la même chose :
public static IEnumerable<T> Wrapper<T>(IEnumerable<T> source)
{
foreach (T element in source)
{
yield return element;
}
}