.NET 4.5Se han añadido dos nuevas interfaces de colección, IReadOnlyList e IReadOnlyDictionary. Aunque estas interfaces puedan parecer tan mundanas en la superficie, revelan historias bastante complejas sobre la compatibilidad hacia atrás, la interoperabilidad y el papel de la comutabilidad.
IReadOnlyList e IReadOnlyDictionary son dos interfaces que los desarrolladores de .NET siempre han querido tener. Además de proporcionar cierta sensación de simetría (en contraposición a interfaces escribibles), una interfaz de solo lectura debería eliminar la implementación de métodos que solo lanzan una excepción NotSupportedException y no hacen nada. Todo esto no se completó debido a limitaciones de tiempo.
La siguiente oportunidad está aquí. NET 2.0. Esto permite a Microsoft retirar colecciones con tipos débiles y reemplazarlas por colecciones de pares con tipos fuertes. Sin embargo, el equipo de la biblioteca base[1] volvió a perder la oportunidad de proporcionar una lista de solo lectura, como escribió Kit George,
Como tenemos la intención de proporcionar una implementación predeterminada para el problema del que hablas con Joe, en lugar de ofrecer una interfaz, proporcionamos la clase base ReadOnlyCollectionBase. Sin embargo, entiendo por qué la gente dude en usarlo porque no es un tipo fuerte. Pero con la introducción de los genéricos, ahora también tenemos <T>ReadOnlyCollection, para que no solo recibas la misma funcionalidad, sino también un tipo fuerte: ¡genial!
Como <T>ReadOnlyCollection no es una clase sellada, puedes escribir tu propia colección a toda velocidad si es necesario. Dado que estas colecciones que hemos creado para esto son adaptables a necesidades generales, no planeamos introducir interfaces para este mismo concepto.
Krzysztof Cwalina también expresó su opinión sobre este tema,
Ya sea sorprendente o no, IList e IList <T>son las dos interfaces que pretendemos usar para colecciones de solo lectura. Ambos tienen la propiedad booleana IsReadOnly (solo lectura), que debería devolver la verdad cuando una colección de solo lectura implementa esta propiedad. La razón por la que no queremos añadir una interfaz puramente de solo lectura es que creemos que añade demasiada complejidad innecesaria a la biblioteca base. Ten en cuenta que, en términos de complejidad, nos referimos tanto a esta nueva interfaz como a sus consumidores.
Creemos que si al diseñador de la API no le importa comprobar la propiedad IsReadOnly en tiempo de ejecución y las excepciones que podría generar, entonces está bien usar la interfaz IList en este caso; Si están dispuestos a ofrecer una API personalizada realmente limpia de una vez, entonces en este caso deberían mostrar la implementación de la interfaz IList y publicar una API de solo lectura personalizada. Esto último es típico de colecciones expuestas a partir del modelo de objetos.
Aunque los desarrolladores se han quejado de esta situación, las nuevas oportunidades que ofrecen los genéricos superan con creces este punto clave y el problema está en . NET 4 fue en gran medida ignorado antes. Sin embargo, esta decisión también provocó algunas reacciones, de las que hablaremos más adelante.
Con la entrada. Se ha añadido una nueva y emocionante función en .NET 4 al entorno de ejecución. En una versión anterior. .NET, cuando las interfaces se convierten en tipos, esas interfaces se restringen en exceso. Por ejemplo, incluso si el Cliente hereda de Persona, no es posible pasar un objeto de tipo IEnumerable <Customer>como parámetro a una función de tipo IEnumerable<Person>. Con la adición de soporte covariante, esta restricción se levantó parcialmente.
Decimos "parcialmente" porque en algunos casos la gente debería usar alguna interfaz con una API rica de golpe, en lugar de usar una interfaz IEnumerable. Aunque la interfaz IList no sea covariante, una interfaz de lista de solo lectura debería serlo. Desafortunadamente, . El equipo de la biblioteca base de .NET ha decidido nuevamente no abordar esta omisión.
Luego la introducción de WinRT y el regreso de COM lo cambiaron todo. La interoperabilidad COM fue en su día una tecnología que los desarrolladores utilizaban cuando no tenían otra opción, pero se ha convertido en un . La piedra angular de la programación .NET. Y dado que WinRT expone las interfaces IVectorView <T>e IMapView<K, V>, por lo tanto. .NET también debe ajustarse en consecuencia.
Una característica interesante del programa WinRT es el anuncio de APIs diferentes pero similares para cada plataforma de desarrollo. Como quizá ya sepas, todos los nombres de los métodos están representados por camelCased [2], mientras que los desarrolladores de C++ y .NET ven los nombres de los métodos como PascalCased [3]. Otro cambio más drástico es el mapeo automático entre las interfaces de C++ y .NET. Por lo tanto. Los desarrolladores de .NET no necesitan lidiar con el espacio de nombres Windows.Foundation.Collections, simplemente seguir usando el espacio de nombres System.Collections.Generic. Las interfaces IVectorView <T>e IMapView<K, V> serán convertidas en tiempo de ejecución en interfaces IReadOnlyList <T>e IReadOnlyDictionary<TKey, TValue>, respectivamente.
Cabe destacar que estos nombres de interfaz en C++/WinRT son más precisos hasta cierto punto. Estas interfaces se utilizan para representar algunas vistas de una colección, pero la interfaz no garantiza que la colección en sí sea inmutable. Incluso entre quienes tienen experiencia. Un error común entre los desarrolladores de .NET es asumir que el tipo ReadOnlyCollection es una copia de una colección inmutable, pero en realidad es solo un envoltorio para una colección activa (véase la publicación de Andrew Arnott con el mismo nombre para más información sobre colecciones de solo lectura, congeladas e inmutables).
Aunque la <T>interfaz IList tiene todos los mismos miembros que la interfaz IReadOnlyList<T>, y todas las listas tipo IList <T>pueden representarse como listas de solo lectura, IList <T>no hereda de IReadOnlyList<T>, lo cual puede ser interesante de aprender. explicó Immo Landwerth,
La razón por la que funciona es porque esas interfaces de solo lectura son puros subconjuntos de las interfaces de lectura-escritura, lo cual parece una suposición razonable. Desafortunadamente, esta suposición no corresponde a la realidad, ya que cada método en cada interfaz a nivel de metadatos tiene su propio espacio (lo que hace que las implementaciones explícitas de interfaces funcionen).
O en otras palabras, la única oportunidad de introducir una interfaz de solo lectura como una clase base variable es recurrir a . NET 2.0, es decir, cuando fueron concebidos originalmente. Una vez que esté completamente desplegado, el único cambio que puede hacer es añadir marcadores covariantes y/o inversores (representados como "in" y "out" en VB y C#).
Cuando le preguntaron por qué no existe <T>la interfaz IReadOnlyCollection, Immo respondió,
Consideramos este diseño, pero consideramos que añadir un tipo que solo proporcionara el atributo Count no aportaría mucho valor a la biblioteca base. En el equipo base de la biblioteca, creemos que si una API empieza en menos 1000, ni siquiera aportar algún valor es suficiente para justificar su añadido. La razón para añadir nuevas APIs también incluye un coste, por ejemplo, los desarrolladores tendrán más conceptos para elegir. Al principio pensamos que añadir este tipo haría que el código funcionara mejor en ciertos escenarios donde solo quieres conseguir un recuento y luego hacer algo interesante con él. Por ejemplo, añadir en gran cantidad a una colección existente. Sin embargo, en estos escenarios, hemos animado a la gente a usar solo la <T>interfaz IEnumerable, y <T>en el caso especial de tener una instancia que implemente la interfaz ICollection. Como todos nuestros tipos de colecciones integrados implementaban esta interfaz, no ha habido ganancia de rendimiento en esos escenarios más comunes. Por cierto, <T>el método de extensión Count() para IEnumerable también puede hacer esto.
Estas nuevas interfaces están disponibles para . NET 4.5 y . NET for Windows 8。
Notas de traducción
[1] Biblioteca de Clase Base, abreviada como BCL. Para más información sobre la biblioteca de la clase base, por favor participa en MSDN.
[2] nomenclatura camel cased, joroba, también conocida como camel case inferior. El formato es que la primera palabra comienza con una letra minúscula; La primera letra de la segunda palabra se escribe con mayúscula, por ejemplo: nombrenombre, apellido.
[3] PascalCased, nomenclatura Pascal, también conocida como la caja camel superior. El formato es que la primera letra de cada palabra se escribe con mayúscula, por ejemplo: NombreNombre, Apellido, CamelCaso. |
Publicado en 5/2/2018 14:28:10
|
|
|
