.NET 4.5Två nya samlingsgränssnitt, IReadOnlyList och IReadOnlyDictionary, har lagts till. Även om dessa gränssnitt kan verka så vardagliga på ytan, avslöjar de ganska komplexa berättelser om bakåtkompatibilitet, interoperabilitet och samföränderlighetens roll.
IReadOnlyList och IReadOnlyDictionary är två gränssnitt som .NET-utvecklare alltid har velat ha. Förutom att ge en viss känsla av symmetri (till skillnad från skrivbara gränssnitt) bör ett skrivskyddat gränssnitt eliminera implementeringen av metoder som bara kastar ett NotSupportedException-undantag och inte gör något. Allt detta blev inte klart på grund av tidsbrist.
Nästa möjlighet är inne. NET 2.0. Detta gör det möjligt för Microsoft att pensionera svagt typade samlingar och ersätta dem med starkt typade peer-samlingar. Men basbiblioteket[1]-teamet missade återigen möjligheten att tillhandahålla en skrivskyddad lista, som Kit George skrev,
Eftersom vi avser att tillhandahålla en standardimplementation för det problem du pratar om med Joe, tillhandahåller vi istället för att ge ett gränssnitt, basklassen ReadOnlyCollectionBase. Men jag kan förstå varför folk är tveksamma till att använda den eftersom det inte är en stark typ. Men med introduktionen av generika har vi nu också ReadOnlyCollection<T>, så att du inte bara får samma funktionalitet, utan också en stark typ: toppen!
Eftersom ReadOnlyCollection <T>inte är en sluten klass kan du skriva din egen samling i full fart om det behövs. Eftersom dessa samlingar vi skapat för detta är anpassningsbara till allmänna behov, planerar vi inte att införa gränssnitt för samma koncept.
Krzysztof Cwalina uttryckte också sin åsikt i detta ämne,
Oavsett om detta låter överraskande eller inte, är IList och IList <T>de två gränssnitt vi avser att använda för skrivskyddade samlingar. Båda har IsReadOnly boolean-egenskapen, som bör returnera true när en skrivskyddad samling implementerar denna egenskap. Anledningen till att vi inte vill lägga till ett rent skrivskyddat gränssnitt är att vi tycker att det tillför för mycket onödig komplexitet till grundbiblioteket. Observera att när det gäller komplexitet syftar vi både på detta nya gränssnitt och dess användare.
Vi anser att om API-designern inte bryr sig om att kontrollera egenskapen IsReadOnly vid körning och de undantag den kan ge, så är det okej att använda IList-gränssnittet i detta fall; Om de är villiga att erbjuda ett riktigt rent anpassat API på en gång, bör de i det här fallet visa implementationen av IList-gränssnittet och publicera ett anpassat skrivskyddat API. Det senare är typiskt för samlingar exponerade från objektmodellen.
Även om utvecklare har klagat på denna situation, överväger de nya möjligheterna generiska spel vida denna kärna och problemet ligger i . NET 4 ignorerades till stor del tidigare. Detta beslut väckte dock också vissa reaktioner, som vi kommer att diskutera senare.
Med in. En spännande ny funktion i .NET 4 har lagts till i speltiden. I en tidigare version. .NET, när gränssnitt blir typer, är dessa gränssnitt alltför begränsade. Till exempel, även om Customer ärver från Person, är det inte möjligt att skicka ett objekt av typen IEnumerable <Customer>som parameter till en funktion av typen IEnumerable<Person>. Med tillägget av kovariant stöd lyftes denna begränsning delvis.
Vi säger "delvis" eftersom folk i vissa fall borde använda ett gränssnitt med ett rikt API på en gång, istället för att använda ett IEtalbart gränssnitt. Även om IList-gränssnittet inte är kovariant, bör ett skrivskyddat listgränssnitt vara det. Tyvärr, . .NET-basbibliotekets team har återigen beslutat att inte ta itu med denna miss.
Sedan förändrades allt med introduktionen av WinRT och COM:s comeback. COM-interoperabilitet var en gång en teknik som utvecklare använde när de inte hade något annat val, men det har blivit en . Hörnstenen i .NET-programmering. Och eftersom WinRT exponerar IVectorView <T>och IMapView<K, V> gränssnitten, därför. .NET måste också justeras därefter.
En intressant funktion i WinRT-programmet är tillkännagivandet av olika men liknande API:er för varje utvecklingsplattform. Som du kanske redan vet representeras alla metodnamn av camelCased [2], medan C++- och .NET-utvecklare ser metodnamn som PascalCased [3]. En annan, mer drastisk förändring är den automatiska mappningen mellan C++- och .NET-gränssnitten. Därför. .NET-utvecklare behöver inte hantera Windows.Foundation.Collections-namnrymden, utan fortsätter bara att använda System.Collections.Generic-namnrymden. IVectorView<T>- och IMapView<K, V>gränssnitten konverteras av körningen till IReadOnlyList-gränssnitt <T>respektive IReadOnlyDictionary<TKey, TValue>gränssnitt.
Det är värt att notera att dessa gränssnittsnamn i C++/WinRT är mer exakta till viss del. Dessa gränssnitt används för att representera vissa vyer av en samling, men gränssnittet säkerställer inte att själva samlingen är oföränderlig. Även bland dem med erfarenhet. Ett vanligt misstag bland .NET-utvecklare är att anta att typen ReadOnlyCollection är en kopia av en oföränderlig samling, men i själva verket bara är ett omslag för en aktiv samling (se Andrew Arnotts inlägg med samma namn för mer information om skrivskyddade, frysta och oföränderliga samlingar).
Även om <T>IList-gränssnittet har alla samma medlemmar som IReadOnlyList-gränssnittet<T>, och alla IList-typlistor <T>kan representeras som skrivskyddade listor, ärver IList <T>inte från IReadOnlyList<T>, vilket kan vara intressant att lära sig om. Immo Landwerth förklarade,
Anledningen till att det fungerar är att dessa skrivskyddade gränssnitt är rena delmängder av läs-skrivgränssnitt, vilket verkar vara en rimlig antagelse. Tyvärr stämmer inte detta antagande överens med verkligheten, eftersom varje metod på varje gränssnitt på metadatanivå har sin egen plats (vilket gör att explicita gränssnittsimplementationer fungerar).
Eller med andra ord, den enda chansen att införa ett skrivskyddat gränssnitt som någon variabel klassbasklass är att falla tillbaka på . NET 2.0, alltså när de ursprungligen skapades. När den är helt utrullad kan den enda förändringen göras att lägga till kovarianta och/eller invertermarkörer (representerade som "in" och "ut" i VB och C#).
När jag frågade varför det inte finns något IReadOnlyCollection-gränssnitt <T>svarade Immo,
Vi övervägde denna design, men vi kände att tillägg av en typ som endast gav attributet Count inte skulle tillföra mycket värde till grundbiblioteket. I basbiblioteksteamet anser vi att om ett API börjar på minus 1000, så räcker inte ens att tillhandahålla något värde för att motivera att det läggs till. Anledningen till att lägga till nya API:er inkluderar också en kostnad, till exempel kommer utvecklare att ha fler koncept att välja mellan. Först trodde vi att om vi lade till den här typen skulle koden prestera bättre i vissa situationer där man bara vill få en räkning och sedan göra något intressant med den. Till exempel, lägg till en befintlig samling i bulk. Men i dessa scenarier har vi uppmuntrat folk att endast använda IEnumerable-gränssnittet<T>, och <T>för det speciella fallet att ha en instans som implementerar ICollection-gränssnittet. Eftersom alla våra inbyggda samlingstyper implementerade detta gränssnitt har det inte skett någon prestandaökning i de vanligaste scenarierna. Förresten <T>kan extensionsmetoden Count() för IEnumerable också göra detta.
Dessa nya gränssnitt finns tillgängliga för . NET 4,5 och . NET for Windows 8。
Översättningsanteckningar
[1] Base Class Library, förkortat BCL. För mer information om basklassens bibliotek, vänligen delta i MSDN.
[2] Kamelhölje, puckelnomenklatur, även känd som nedre kamelhylsa. Formatet är att det första ordet börjar med en liten bokstav; Den första bokstaven i det andra ordet är med stor versal, till exempel: förnamn, efternamn.
[3] PascalCased, Pascal-nomenklatur, även känd som övre kamel-förfallet. Formatet är att den första bokstaven i varje ord är versaliserad, till exempel: FirstName, LastName, CamelCase. |
Publicerad på 2018-02-05 14:28:10
|
|
|
