.NET 4.5To nye samlingsgrænseflader, IReadOnlyList og IReadOnlyDictionary, er blevet tilføjet. Selvom disse grænseflader kan virke så trivielle på overfladen, afslører de ret komplekse historier om bagudkompatibilitet, interoperabilitet og co-mutabilitetens rolle.
IReadOnlyList og IReadOnlyDictionary er to grænseflader, som .NET-udviklere altid har ønsket at have. Ud over at give en vis symmetri (i modsætning til skrivbare grænseflader) bør en skrivebeskyttet grænseflade eliminere implementeringen af metoder, der kun kaster en NotSupportedException-undtagelse og ikke gør noget. Alt dette blev ikke gennemført på grund af tidsmæssige begrænsninger.
Den næste mulighed er inde. NET 2.0. Dette gør det muligt for Microsoft at pensionere svagt typede samlinger og erstatte dem med stærkt typede peer-samlinger. Dog gik basebiblioteket[1]-teamet endnu engang glip af muligheden for at levere en læsebeskyttet liste, som Kit George skrev,
Da vi har til hensigt at levere en standardimplementering til det problem, du taler om med Joe, i stedet for at give et interface, tilbyder vi ReadOnlyCollectionBase-baseklassen. Men jeg kan godt forstå, hvorfor folk er tilbageholdende med at bruge det, fordi det ikke er en stærk type. Men med introduktionen af generiske produkter har vi nu også ReadOnlyCollection<T>, så du ikke kun får samme funktionalitet, men også en stærk type: fantastisk!
Da ReadOnlyCollection <T>ikke er en lukket klasse, kan du skrive din egen samling med fuld hastighed, hvis nødvendigt. Fordi disse samlinger, vi har skabt til dette, kan tilpasses generelle behov, planlægger vi ikke at introducere grænseflader til dette samme koncept.
Krzysztof Cwalina udtrykte også sin mening om dette emne,
Uanset om det lyder overraskende eller ej, er IList og IList <T>de to grænseflader, vi har til hensigt at bruge til skrivebeskyttede samlinger. Begge har IsReadOnly boolean-egenskaben, som bør returnere true, når en read-only-samling implementerer denne egenskab. Grunden til, at vi ikke ønsker at tilføje en ren skrivebeskyttet grænseflade, er, at vi føler, det tilføjer for meget unødvendig kompleksitet til basisbiblioteket. Bemærk, at vi i forhold til kompleksitet refererer både til dette nye interface og dets forbrugere.
Vi mener, at hvis API-designeren ikke bekymrer sig om at tjekke IsReadOnly-egenskaben under kørsel og de undtagelser, den kan kaste, så er det okay at bruge IList-interfacet i dette tilfælde; Hvis de er villige til at levere en virkelig ren, brugerdefineret API på én gang, bør de i dette tilfælde vise implementeringen af IList-grænsefladen og udgive en skræddersyet read-only API. Sidstnævnte er typisk for samlinger eksponeret fra objektmodellen.
Selvom udviklere har klaget over denne situation, opvejer de nye muligheder, som generiske spil giver, langt dette kernepunkt, og problemet ligger i . NET 4 blev stort set ignoreret før. Denne beslutning udløste dog også nogle reaktioner, som vi vil diskutere senere.
Med indgangen. En spændende ny funktion i .NET 4 er blevet tilføjet til spilletiden. I en tidligere version. .NET, når grænseflader bliver typer, er disse grænseflader alt for begrænsede. For eksempel, selv hvis Kunde arver fra Person, er det ikke muligt at overføre et objekt af typen IEnumerable <Customer>som parameter til en funktion af typen IEnumerable<Person>. Med tilføjelsen af kovariant støtte blev denne begrænsning delvist ophævet.
Vi siger "delvist", fordi folk i nogle tilfælde bør bruge et interface med et rigt API på én gang, i stedet for at bruge et IEtalbart interface. Selv hvis IList-grænsefladen ikke er kovariant, bør en skrivebeskyttet listegrænseflade være det. Desværre, . .NET-basebibliotekets team har igen besluttet ikke at tage fat på denne forglemmelse.
Så ændrede introduktionen af WinRT og COM's comeback alt. COM-interoperabilitet var engang en teknologi, som udviklere brugte, når de ikke havde andre muligheder, men det er blevet en . Hjørnestenen i .NET-programmering. Og da WinRT eksponerer IVectorView <T>og IMapView<K, V> grænsefladerne, derfor. .NET skal også justeres derefter.
En interessant funktion ved WinRT-programmet er annonceringen af forskellige, men lignende API'er for hver udviklingsplatform. Som du måske allerede ved, repræsenteres alle metodenavne med camelCased [2], mens C++- og .NET-udviklere ser metodenavne som PascalCased [3]. En anden, mere drastisk ændring er den automatiske mapping mellem C++- og .NET-grænsefladerne. Derfor. .NET-udviklere behøver ikke at håndtere Windows.Foundation.Collections-navnerummet, men fortsætter blot med at bruge System.Collections.Generic-navneområdet. IVectorView<T>- og IMapView<K, V>-grænsefladerne vil blive konverteret af kørseltiden til henholdsvis IReadOnlyList-grænseflader <T>og IReadOnlyDictionary<TKey, TValue> grænseflader.
Det er værd at bemærke, at disse grænsefladenavne i C++/WinRT til en vis grad er mere præcise. Disse grænseflader bruges til at repræsentere nogle visninger af en samling, men grænsefladen sikrer ikke, at selve samlingen er uforanderlig. Selv blandt dem med erfaring. En almindelig fejl blandt .NET-udviklere er at antage, at ReadOnlyCollection-typen er en kopi af en uforanderlig samling, men i virkeligheden blot er en wrapper for en aktiv samling (se Andrew Arnotts indlæg med samme navn for mere information om skrivebeskyttede, frosne og uforanderlige samlinger).
Selvom <T>IList-grænsefladen har alle de samme medlemmer som IReadOnlyList-grænsefladen<T>, og alle IList-typer <T>lister kan repræsenteres som skrivebeskyttede lister, arver IList <T>ikke fra IReadOnlyList<T>, hvilket kan være interessant at lære om. Immo Landwerth forklarede,
Grunden til, at det virker, er, at disse skrivebeskyttede grænseflader er rene delmængder af læse-skrive-grænseflader, hvilket virker som en rimelig antagelse. Desværre stemmer denne antagelse ikke overens med virkeligheden, da hver metode på hver grænseflade på metadata-niveau har sin egen plads (hvilket gør eksplicitte interface-implementeringer effektive).
Eller med andre ord, den eneste chance for at indføre en skrivebeskyttet grænseflade som en variabel klassebaseklasse er at falde tilbage til . NET 2.0, altså da de oprindeligt blev skabt. Når den er fuldt udrullet, er den eneste ændring, den kan foretage, at tilføje kovariante og/eller invertermarkører (repræsenteret som "ind" og "ud" i VB og C#).
Da jeg blev spurgt, hvorfor der ikke findes et IReadOnlyCollection-interface<T>, svarede Immo:
Vi overvejede dette design, men vi følte, at tilføjelse af en type, der kun tilbød Count-attributtet, ikke ville tilføre basisbiblioteket meget værdi. I basisbiblioteksteamet mener vi, at hvis et API starter ved minus 1000, så er det ikke nok at tilføre en vis værdi til at retfærdiggøre tilføjelsen. Begrundelsen for at tilføje nye API'er inkluderer også en omkostning, for eksempel vil udviklere have flere koncepter at vælge imellem. Først troede vi, at tilføjelsen af denne type ville få koden til at fungere bedre i visse situationer, hvor man bare vil have en optælling og så lave noget interessant med den. For eksempel kan man tilføje til en eksisterende samling i store mængder. Men i disse scenarier har vi opfordret folk til kun at bruge IEtallable-grænsefladen<T>, og <T>i det særlige tilfælde at have en instans, der implementerer ICollection-grænsefladen. Da alle vores indbyggede samlingstyper implementerede dette interface, har der ikke været nogen ydelsesforbedring i de mest almindelige scenarier. For resten <T>kan udvidelsesmetoden Count() for IEnumerable også gøre dette.
Disse nye grænseflader er tilgængelige for . NET 4,5 og . NET for Windows 8。
Oversættelsesnoter
[1] Base Class Library, forkortet BCL. For mere information om basisklassebiblioteket, deltag venligst i MSDN.
[2] KamelHyldet, pukkel-nomenklatur, også kendt som nedre kamel-hule. Formatet er, at det første ord begynder med et lille bogstav; Det første bogstav i det andet ord skrives med stort bogstav, for eksempel: firstName, efternavn.
[3] PascalCased, Pascal-nomenklatur, også kendt som den øvre kamel-type. Formatet er, at det første bogstav i hvert ord skrives med stort begyndelsesbogstav, for eksempel: Fornavn, Efternavn, KamelKasse. |
Opslået på 05/02/2018 14.28.10
|
|
|
