.NET 4.5Twee nieuwe verzamelinterfaces, IReadOnlyList en IReadOnlyDictionary, zijn toegevoegd. Hoewel deze interfaces op het eerste gezicht zo alledaags lijken, onthullen ze vrij complexe verhalen over achterwaartse compatibiliteit, interoperabiliteit en de rol van co-mutabiliteit.
IReadOnlyList en IReadOnlyDictionary zijn twee interfaces die .NET-ontwikkelaars altijd al wilden hebben. Naast het bieden van een gevoel van symmetrie (in tegenstelling tot beschrijfbare interfaces), zou een alleen-lezen interface de implementatie van methoden die alleen een NotSupportedException-uitzondering gooien en niets doen, moeten elimineren. Dit alles werd niet voltooid vanwege tijdsdruk.
De volgende kans is binnen. NET 2.0. Dit stelt Microsoft in staat om zwak getypte collecties met pensioen te trekken en te vervangen door sterk getypeerde peer-collecties. Echter, het team van de basisbibliotheek[1] miste opnieuw de kans om een alleen-lezen lijst te geven, zoals Kit George schreef,
Omdat we van plan zijn een standaardimplementatie te bieden voor het probleem waar je het over hebt met Joe, bieden we in plaats van een interface de basisklasse ReadOnlyCollectionBase aan. Toch begrijp ik waarom mensen terughoudend zijn om het te gebruiken, omdat het geen sterk type is. Maar met de introductie van generieke producten hebben we nu ook ReadOnlyCollection<T>, zodat je niet alleen dezelfde functionaliteit krijgt, maar ook een sterk type: geweldig!
Omdat ReadOnlyCollection <T>geen gesloten klasse is, kun je indien nodig je eigen collectie op volle snelheid schrijven. Omdat deze collecties die we hiervoor hebben gemaakt aanpasbaar zijn aan algemene behoeften, zijn we niet van plan interfaces voor ditzelfde concept te introduceren.
Krzysztof Cwalina gaf ook zijn mening over dit onderwerp,
Of dit nu verrassend klinkt of niet, IList en IList <T>zijn de twee interfaces die we willen gebruiken voor alleen-lezen collecties. Beide hebben de booleaanse eigenschap IsReadOnly, die true zou moeten teruggeven wanneer een alleen-lezen collectie deze eigenschap implementeert. De reden dat we geen puur alleen-lezen interface willen toevoegen, is omdat we vinden dat het te veel onnodige complexiteit toevoegt aan de basisbibliotheek. Let op dat we qua complexiteit verwijzen naar zowel deze nieuwe interface als zijn gebruikers.
Wij denken dat als de API-ontwerper zich niet druk maakt om het controleren van de IsReadOnly-eigenschap tijdens runtime en de mogelijke uitzonderingen, het in dit geval prima is om de IList-interface te gebruiken; Als ze bereid zijn om in één keer een echt schone, aangepaste API te leveren, dan zouden ze in dit geval de implementatie van de IList-interface moeten laten zien en een op maat gemaakte read-only API moeten publiceren. Dit laatste is typisch voor collecties die vanuit het objectmodel worden blootgesteld.
Hoewel ontwikkelaars over deze situatie hebben geklaagd, wegen de nieuwe kansen die generieke games bieden ruimschoots op tegen deze kern en ligt het probleem in . NET 4 werd voorheen grotendeels genegeerd. Deze beslissing riep echter ook enkele reacties op, waar we later op zullen ingaan.
Met de in. Er is een spannende nieuwe functie toegevoegd aan .NET 4 aan de runtime. In een eerdere versie. .NET, wanneer interfaces types worden, zijn die interfaces te beperkt. Bijvoorbeeld, zelfs als Klant van Persoon erft, is het niet mogelijk om een object van type IEnumerable <Customer>als parameter door te geven aan een functie van type IEnumerable<Person>. Met de toevoeging van covariante ondersteuning werd deze beperking gedeeltelijk opgeheven.
We zeggen "gedeeltelijk" omdat mensen in sommige gevallen een interface met een rijke API tegelijk zouden moeten gebruiken, in plaats van een IEnumerable interface te gebruiken. Zelfs als de IList-interface niet covariant is, zou een alleen-lezen lijstinterface dat wel moeten zijn. Helaas, . Het .NET basisbibliotheekteam heeft opnieuw besloten deze nalatigheid niet aan te pakken.
Toen veranderde de introductie van WinRT en de comeback van COM alles. COM-interoperabiliteit was ooit een technologie die ontwikkelaars gebruikten als ze geen andere keuze hadden, maar het is een . De hoeksteen van .NET-programmeren. En aangezien WinRT de IVectorView<T>- en IMapView<K-interfaces blootstelt, V> dus .NET moet ook dienovereenkomstig worden aangepast.
Een interessant kenmerk van het WinRT-programma is de aankondiging van verschillende maar vergelijkbare API's voor elk ontwikkelplatform. Zoals je misschien al weet, worden alle methodenamen weergegeven door camelCased [2], terwijl ontwikkelaars in C++ en .NET methodenamen als PascalCased [3] zien. Een andere, ingrijpendere verandering is de automatische koppeling tussen de C++- en .NET-interfaces. Daarom. .NET-ontwikkelaars hoeven niet met de Windows.Foundation.Collections-naamruimte om te gaan, maar blijven gewoon de System.Collections.Generic naamruimte gebruiken. De IVectorView<T>- en IMapView<K, V>-interfaces worden door de runtime omgezet naar <T>respectievelijk IReadOnlyList-interfaces en IReadOnlyDictionary<TKey, TValue> interfaces.
Het is vermeldenswaard dat deze interfacenamen in C++/WinRT tot op zekere hoogte nauwkeuriger zijn. Deze interfaces worden gebruikt om sommige weergaven van een collectie weer te geven, maar de interface zorgt er niet voor dat de collectie zelf onveranderlijk is. Zelfs onder degenen met ervaring. Een veelgemaakte fout onder .NET-ontwikkelaars is aan te nemen dat het type ReadOnlyCollection een kopie is van een onveranderlijke collectie, maar in werkelijkheid slechts een wrapper is voor een actieve collectie (zie het gelijknamige bericht van Andrew Arnott voor meer informatie over alleen-lezen, bevroren en onveranderlijke collecties).
Hoewel de <T>IList-interface alle leden heeft als de IReadOnlyList-interface<T>, en alle IList-achtige <T>lijsten als alleen-lezen lijsten kunnen worden weergegeven, erft IList <T>niet van IReadOnlyList<T>, wat interessant kan zijn om over te leren. Immo Landwerth legde uit,
De reden dat het werkt is omdat die alleen-lezen interfaces pure subsets zijn van lees-schrijfinterfaces, wat een redelijke aanname lijkt. Helaas komt deze aanname niet overeen met de werkelijkheid, aangezien elke methode op elke interface op metadata-niveau zijn eigen slot heeft (waardoor expliciete interface-implementaties werken).
Of met andere woorden, de enige kans om een alleen-lezen interface als een variabele klassebasisklasse te introduceren, is om terug te vallen op . NET 2.0, oftewel wanneer ze oorspronkelijk zijn bedacht. Zodra het volledig is uitgerold, is de enige verandering die het kan aanbrengen het toevoegen van covariante en/of invertermarkeringen (weergegeven als "in" en "out" in VB en C#).
Toen hem werd gevraagd waarom er geen IReadOnlyCollection-interface is<T>, antwoordde Immo:
We hebben dit ontwerp overwogen, maar we vonden dat het toevoegen van een type dat alleen het Count-attribuut levert, weinig waarde zou toevoegen aan de basisbibliotheek. In het basisbibliotheekteam geloven we dat als een API begint bij min 1000, zelfs het bieden van enige waarde niet genoeg is om toegevoegd te worden. De reden voor het toevoegen van nieuwe API's omvat ook een kosten, bijvoorbeeld dat ontwikkelaars meer concepten kunnen kiezen. In eerste instantie dachten we dat het toevoegen van dit type de code beter zou laten presteren in bepaalde situaties waarin je gewoon een telling wilt maken en er dan iets interessants mee wilt doen. Bijvoorbeeld, bulk toevoegen aan een bestaande collectie. In deze scenario's hebben we mensen echter aangemoedigd alleen de IEtallable-interface te gebruiken<T>, en <T>voor het speciale geval van een instantie die de ICollection-interface implementeert. Aangezien al onze ingebouwde verzamelingstypes deze interface hebben geïmplementeerd, is er geen prestatieverbetering geweest in die meest voorkomende scenario's. Trouwens, <T>de extensiemethode Count() voor IEnumerable kan dit ook.
Deze nieuwe interfaces zijn beschikbaar voor . NET 4,5 en . NET for Windows 8。
Vertaalnotities
[1] Basisklasse Bibliotheek, afgekort als BCL. Voor meer informatie over de basisklasbibliotheek, neem deel aan MSDN.
[2] kameelomlijsting, bult-nomenclatuur, ook bekend als lagere kameelval. Het format is dat het eerste woord begint met een kleine letter; De eerste letter van het tweede woord wordt met een hoofdletter geschreven, bijvoorbeeld: voornaam, achternaam.
[3] PascalCased, Pascal-nomenclatuur, ook bekend als de hoge kameelnaam. Het format is dat de eerste letter van elk woord met een hoofdletter wordt geschreven, bijvoorbeeld: Voornaam, Achternaam, KameelKoffer. |
Geplaatst op 05-02-2018 14:28:10
|
|
|
