¿Por qué ReadOnlyCollection <> no incluye métodos como FindAll(), FindFirst(),

Question

? Siguiendo las sugerencias de FxCop y mi inclinación personal, he estado animando al equipo que estoy entrenando a utilizar ReadOnlyCollections tanto como sea posible. Si solo para que los destinatarios de las listas no puedan modificar su contenido. En su teoría, esto es pan & mantequilla. El problema es que la interfaz List <> es mucho más rica y expone todo tipo de métodos útiles. ¿Por qué hicieron esa elección?

¿Acaba de renunciar y devolver colecciones de escritura? ¿Devuelve colecciones de solo lectura y luego las envuelve en la variedad de escritura? Ahhhhh.

---

Actualización: Gracias estoy familiarizado con el Marco de Diseño directriz y es por eso que el equipo está usando FxCop para hacerla cumplir. Sin embargo, este equipo vive con VS 2005 (lo sé, lo sé) y por eso, decirles que los métodos LINQ/Extension resolverían sus problemas simplemente los entristece.

Han aprendido que List.FindAll() y .FindFirst() proporcionan una mayor claridad que la escritura de un bucle foreach. Ahora los presiono para que utilicen ReadOnlyCollections, pierden esa claridad.

Quizás haya un problema de diseño más profundo que no estoy detectando.

- Lamento que la publicación original debería haber mencionado la restricción VS2005. He vivido tanto tiempo que simplemente no me doy cuenta.

Answer 1

Sección 8.3.2 de la .NET Framework Design Guidelines Second Edition:

DO uso ReadOnlyCollection<T>, una subclase de ReadOnlyCollection<T>, o en casos raros IEnumerable<T> para las propiedades o valores que representan sólo lectura colecciones volver.

Vamos con ReadOnlyCollections para expresar nuestra intención de la colección devuelta.

Los métodos List<T> de los que habla se agregaron en .NET 2.0 para su comodidad. En C# 3.0/.NET 3.5, puede volver a obtener todos esos métodos en ReadOnlyCollection<T> (o IEnumerable<T>) usando métodos de extensión (y también usar operadores LINQ), así que no creo que haya ninguna motivación para agregarlos de forma nativa a otros tipos . El hecho de que existan en absoluto en List es solo una nota histórica debido a la presencia de métodos de extensión disponibles ahora pero que no estaban en 2.0.

Answer 2

No tengo ninguna idea de por qué no se agregaron originalmente. Pero ahora que tenemos LINQ, ciertamente no veo razón para agregarlos en futuras versiones del lenguaje. Los métodos que mencionaste pueden escribirse fácilmente en una consulta LINQ hoy. Estos días solo uso las consultas LINQ para casi todo. De hecho, me enojo más a menudo con List<T> teniendo esos métodos porque entra en conflicto con los métodos de extensión que escribo contra IEnumerable<T>.

Answer 3

En primer lugar, ReadOnlyCollection<T> implementa IEnumerable<T> y IList<T>. Con todos los métodos de extensión en .NET 3.5 y LINQ, tiene acceso a casi toda la funcionalidad de la clase original List<T> en términos de consultas, que es todo lo que debe hacer con un ReadOnlyCollection<T>.

Habiendo dicho eso, su pregunta inicial me lleva a hacer algunas sugerencias ...

De vuelta List<T> es un mal diseño, por lo que no debería ser un punto de comparación. List<T> se debe utilizar para la implementación, pero para la interfaz, se debe devolver IList<T>. El estado Framework Design Guidelines específicamente:

"NO uso ArrayList o List<T> en API públicas." (Página 251)

Si tiene esto en cuenta, no hay absolutamente ninguna desventaja en ReadOnlyCollection<T> en comparación con List<T>. Ambas clases implementan IEnumerable<T> y IList<T>, que son las interfaces que deben devolverse de todos modos.

Answer 4

Creo que la respuesta de Jeff contiene la respuesta que necesita; en lugar de ReadOnlyCollection<T>, devuelva una subclase ... una que implemente usted mismo para incluir los métodos que le gustaría usar sin actualizar a VS2008/LINQ.