.NET 4.5Lisatud on kaks uut koguliidest, IReadOnlyList ja IReadOnlyDictionary. Kuigi need liidesed võivad pealtnäha tunduda igavad, paljastavad need üsna keerukaid lugusid tagurpidi ühilduvusest, koostalitlusvõimest ja ko-mutability rollist.
IReadOnlyList ja IReadOnlyDictionary on kaks liidest, mida .NET arendajad on alati soovinud. Lisaks sümmeetriatunde pakkumisele (erinevalt kirjutatavatest liidestest) peaks ainult lugemiseks mõeldud liides välistama meetodite rakendamise, mis viskavad ainult NotSupportedException erandi ega tee midagi. Kõik see jäi ajapuuduse tõttu lõpetamata.
Järgmine võimalus on käes. NET 2.0. See võimaldab Microsoftil nõrgalt tüübitud kogud pensionile saata ja asendada need tugevalt tüübistatud eakaaslaste kogudega. Kuid baasi raamatukogu[1] meeskond jättis taas kasutamata võimaluse pakkuda ainult lugemiseks mõeldud nimekiri, nagu Kit George kirjutas,
Kuna kavatseme pakkuda vaikimisi lahendust probleemile, millest Joe puhul räägid, siis liidest asemel pakume ReadOnlyCollectionBase baasklassi. Kuid ma saan aru, miks inimesed on selle kasutamise suhtes vastumeelsed, sest see pole tugev tüüp. Kuid geneeriliste kasutuselevõtuga on meil nüüd ka ReadOnlyCollection<T>, nii et saad mitte ainult sama funktsionaalsuse, vaid ka tugeva tüübi: suurepärane!
Kuna ReadOnlyCollection <T>ei ole suletud kursus, saad vajadusel kirjutada oma kogumiku täiskiirusel. Kuna need kogud, mille oleme selleks loonud, on kohandatavad üldiste vajadustega, ei plaani me sama kontseptsiooni jaoks liideseid lisada.
Krzysztof Cwalina avaldas samuti oma arvamust sellel teemal,
Kas see kõlab üllatavalt või mitte, IList ja IList <T>on kaks liidest, mida kavatseme kasutada ainult lugemiseks mõeldud kogumikes. Mõlemal on IsReadOnly boole'i omadus, mis peaks tagastama tõe, kui ainult lugemiseks mõeldud kogum selle omaduse rakendab. Põhjus, miks me ei taha lisada puhtalt ainult lugemiseks mõeldud liidest, on see, et see lisab baasteekile liiga palju tarbetut keerukust. Pane tähele, et keerukuse mõistes viitame nii uuele liidesele kui ka selle tarbijatele.
Usume, et kui API disainerile ei ole oluline kontrollida IsReadOnly omadust käitusajal ja selle võimalikke erandeid, siis on selles olukorras täiesti okei kasutada IList liidest; Kui nad on valmis pakkuma tõeliselt puhast kohandatud API-d korraga, siis sel juhul peaksid nad näitama IList liidese rakendust ja avaldama kohandatud ainult lugemiseks mõeldud API. Viimane on tüüpiline objektimudelist paljastatud kogude puhul.
Kuigi arendajad on selle olukorra üle kurtnud, kaaluvad generikumide pakutavad uued võimalused selle tuuma kaugele üles ja probleem on . NET 4 oli varem suuresti tähelepanuta. Kuid see otsus tekitas ka mõningaid reaktsioone, millest räägime hiljem.
Koos sellega. .NET 4-s on mänguajale lisatud põnev uus funktsioon. Varasemas versioonis. .NET, kui liidesed muutuvad tüüpideks, on need liidesed liigselt piiratud. Näiteks, isegi kui klient pärib Isikult, ei ole võimalik IEnumerable tüüpi objekti <Customer>parameetrina edasi anda funktsioonile, mille tüüp on IEnumerable<Person>. Kovariantide toe lisamisega kaotati see piirang osaliselt.
Me ütleme "osaliselt", sest mõnel juhul peaksid inimesed kasutama mingit liidest rikkaliku API-ga korraga, mitte IEnumerable'i liidest. Isegi kui IList liides ei ole kovariantne, peaks olema ainult lugemiseks mõeldud listliides. Kahjuks . .NET baasteegi meeskond on taas otsustanud seda möödalaskmist mitte lahendada.
Siis muutis WinRT ja COM-i tagasitulek kõik. COM-ühilduvus oli kunagi tehnoloogia, mida arendajad kasutasid, kui neil polnud muud valikut, kuid sellest on saanud . .NET programmeerimise nurgakivi. Ja kuna WinRT avab IVectorView <T>ja IMapView<K, siis V> liidesed. .NET tuleb samuti vastavalt kohandada.
Üks WinRT programmi huvitav omadus on iga arendusplatvormi jaoks erinevate, kuid sarnaste API-de väljakuulutamine. Nagu te võib-olla juba teate, on kõik meetodi nimed esindatud camelCased'iga [2], samas kui C++ ja .NET arendajad näevad meetodite nimesid kui PascalCased [3]. Teine drastilisem muudatus on automaatne kaardistamine C++ ja .NET liideste vahel. Seega. .NET arendajad ei pea tegelema Windows.Foundation.Collections nimeruumiga, lihtsalt jätkavad System.Collections.Generic nimeruumi kasutamist. IVectorView <T>ja IMapView<K, V> liidesed teisendatakse jooksuajal vastavalt IReadOnlyList <T>liidesteks ja IReadOnlyDictionary<TKey, TValue> liidesteks.
Tasub märkida, et need liidese nimed C++/WinRT-s on teatud määral täpsemad. Neid liideseid kasutatakse mõnede kollektsioonivaadete esitamiseks, kuid liides ei taga, et kogu ise on muutumatu. Isegi nende seas, kellel on kogemusi. Levinud viga .NET arendajate seas on eeldada, et ReadOnlyCollection tüüp on muutumatu kollektsiooni koopia, kuid tegelikult on see lihtsalt aktiivse kogu ümbris (vt Andrew Arnotti samanimelist postitust, et saada rohkem teavet ainult lugemise, külmutatud ja muutumatute kogude kohta).
Kuigi IListi <T>liides sisaldab kõiki samu liikmeid nagu IReadOnlyList <T>liides ja kõiki IList-tüüpi <T>loendeid saab esitada ainult lugemiseks mõeldud loenditena, ei päri IList <T>IReadOnlyListist<T>, mis võib olla huvitav õppida. Immo Landwerth selgitas,
Põhjus, miks see töötab, on see, et need ainult lugemiseks mõeldud liidesed on puhtad lugemis-kirjutamise liideste alamhulgad, mis tundub mõistlik oletus. Kahjuks see eeldus ei vasta reaalsusele, kuna igal meetodil igal liidesel metaandmete tasemel on oma pesa (mis teeb eksplicitsete liidese rakenduste toimivaks).
Teisisõnu, ainus võimalus tutvustada ainult lugemiseks mõeldud liidest mõne muutuva klassi baasklassina on tagasi pöörduda . NET 2.0, st siis, kui need algselt sündisid. Kui see on täielikult kasutusele võetud, saab ainus muudatus lisada kovariantseid ja/või inverteri markereid (VB ja C# puhul tähistatud kui "sisse" ja "välja").
Kui küsiti, miks IReadOnlyCollection <T>liidest pole, vastas Immo:
Me kaalusime seda disaini, kuid tundsime, et tüübi lisamine, mis annab ainult Count atribuudi, ei lisa baasteegile suurt väärtust. Baasiteegi tiimis usume, et kui API algab miinus 1000-st, siis isegi mingi väärtuse pakkumine ei õigusta lisamist. Uute API-de lisamise põhjenduseks on ka kulu, näiteks arendajatel on rohkem kontseptsioone, mille vahel valida. Alguses arvasime, et selle tüübi lisamine parandab koodi teatud olukordades, kus tahad lihtsalt loendada ja sellega midagi huvitavat teha. Näiteks lisada hulgi olemasolevale kollektsioonile. Kuid nendes olukordades oleme julgustanud inimesi kasutama ainult IEnumerable'i <T>liidest ning <T>erijuhtumiks, kus on instant, mis rakendab ICollection liidest. Kuna kõik meie sisseehitatud kollektsioonitüübid on selle liidese rakendanud, pole nende kõige levinumate olukordade puhul jõudluse paranemist olnud. Muide, <T>laiendusmeetod Count() IEnumerable'i jaoks suudab seda samuti teha.
Need uued liidesed on saadaval . NET 4.5 ja . NET for Windows 8。
Tõlkemärkused
[1] Baasklassi raamatukogu, lühendatult BCL. Lisateabe saamiseks baasklasside raamatukogu kohta palun osalege MSDN-is.
[2] CamelCased, küürnimetus, tuntud ka kui alumine kaamelikorpus. Formaat on selline, et esimene sõna algab väikese tähega; Teise sõna esimene täht on suurtähtedega, näiteks: eesnimi, perekonnanimi.
[3] PascalCased, Pascal nomenklatuur, tuntud ka kui ülemine kaamelikarp. Formaat on selline, et iga sõna esimene täht on suurtähtedega, näiteks: Eesnimi, Perekonnanimi, KaameliJuhtum. |
Postitatud 05.02.2018 14:28:10
|
|
|
