.NET 4.5Kaksi uutta kokoelmakäyttöliittymää, IReadOnlyList ja IReadOnlyDictionary, on lisätty. Vaikka nämä rajapinnat saattavat pinnalta näyttää niin arkisilta, ne paljastavat melko monimutkaisia tarinoita taaksepäin yhteensopivuudesta, yhteentoimivuudesta ja yhteismuuntautumisen roolista.
IReadOnlyList ja IReadOnlyDictionary ovat kaksi käyttöliittymää, joita .NET-kehittäjät ovat aina halunneet saada. Vain luku -rajapinta tarjoaa jonkinlaisen symmetrian tunteen (toisin kuin kirjoitettavat rajapinnat), ja sen pitäisi poistaa metodien toteutus, jotka heittävät vain NotSupportedException-poikkeuksen eivätkä tee mitään. Kaikki tämä jäi tekemättä aikataulujen vuoksi.
Seuraava tilaisuus on tullut. NET 2.0. Tämä mahdollistaa Microsoftille heikosti tyypitetyt kokoelmat eläkkeelle jättämisen ja niiden korvaamisen vahvasti tyypitettyillä vertaiskokoelmilla. Kuitenkin tukikohdan kirjasto[1] tiimi menetti jälleen mahdollisuuden tarjota vain luku -listaa, kuten Kit George kirjoitti,
Koska aiomme tarjota oletustoteutuksen ongelmalle, josta puhut Joen kanssa, emme rajapintaa, vaan tarjoamme ReadOnlyCollectionBase-perusluokan. Ymmärrän kuitenkin, miksi ihmiset epäröivät käyttää sitä, koska se ei ole vahva tyyppi. Mutta geneeristen versioiden myötä meillä on nyt myös ReadOnlyCollection<T>, joten saat paitsi saman toiminnallisuuden, myös vahvan tyypin: loistavaa!
Koska ReadOnlyCollection <T>ei ole sinetöity kurssi, voit tarvittaessa kirjoittaa oman kokoelmasi täydellä nopeudella. Koska nämä kokoelmat, jotka olemme luoneet tätä varten, mukautuvat yleisiin tarpeisiin, emme aio ottaa käyttöön rajapintoja samaan konseptiin.
Krzysztof Cwalina ilmaisi myös mielipiteensä tästä aiheesta,
Kuulostaako tämä yllättävältä tai ei, IList ja IList <T>ovat kaksi käyttöliittymää, joita aiomme käyttää vain luku -kokoelmiin. Molemmissa on IsReadOnly -boolean-ominaisuus, jonka pitäisi palauttaa true, kun vain luku -kokoelma toteuttaa tämän ominaisuuden. Syynä siihen, ettemme halua lisätä pelkkää vain luku -käyttöliittymää, on se, että koemme sen tuovan liikaa tarpeetonta monimutkaisuutta peruskirjastoon. Huomaa, että monimutkaisuuden kannalta viittaamme sekä tähän uuteen käyttöliittymään että sen kuluttajiin.
Uskomme, että jos API-suunnittelijaa ei kiinnosta tarkistaa IsReadOnly -ominaisuus ajonaikaisesti ja poikkeuksia, on ok käyttää IList-käyttöliittymää tässä tapauksessa; Jos he ovat valmiita tarjoamaan todella puhtaan räätälöidyn API:n kerralla, tässä tapauksessa heidän tulisi näyttää IList-käyttöliittymän toteutus ja julkaista räätälöity vain luku -rajapinta. Jälkimmäinen on tyypillinen kokoelmille, jotka on paljastettu objektimallista.
Vaikka kehittäjät ovat valittaneet tästä tilanteesta, geneeristen tarjoamat uudet mahdollisuudet ylittävät tämän ytimen, ja ongelma on . NET 4 jätettiin aiemmin suurelta osin huomiotta. Tämä päätös herätti kuitenkin myös reaktioita, joista keskustelemme myöhemmin.
Sisäänpääsyn kanssa. Jännittävä uusi ominaisuus .NET 4:ään on lisätty ajonaikaan. Aikaisemmassa versiossa. .NET, kun rajapinnat muuttuvat tyypeiksi, nämä rajapinnat ovat liikaa rajoitettuja. Esimerkiksi, vaikka asiakas perisi Personilta, ei ole mahdollista välittää IEnumerable-tyyppistä <Customer>objektia parametrina funktiolle, jonka tyyppi on IEnumerable<Person>. Kovarianttituen lisäämisen myötä tämä rajoitus osittain poistettiin.
Sanomme "osittain", koska joissain tapauksissa ihmisten pitäisi käyttää yhtä rajapintaa, jossa on rikas API, sen sijaan että käyttäisivät IEnumerable-rajapintaa. Vaikka IListin käyttöliittymä ei olisi kovariantti, vain luku -lista -käyttöliittymä pitäisi olla. Valitettavasti, . .NET-pohjakirjastotiimi on jälleen päättänyt olla puuttumatta tähän puutteeseen.
Sitten WinRT:n tulo ja COM:n paluu muuttivat kaiken. COM-yhteensopivuus oli aikoinaan teknologia, jota kehittäjät käyttivät silloin, kun heillä ei ollut muuta vaihtoehtoa, mutta siitä on tullut . .NET-ohjelmoinnin kulmakivi. Ja koska WinRT avaa IVectorView<T>- ja IMapView<K-rajapinnat, V>-rajapinnat. .NET:iä on myös säädettävä sen mukaisesti.
Yksi WinRT-ohjelman mielenkiintoinen ominaisuus on erilaisten mutta samankaltaisten rajapintojen julkistus jokaiselle kehitysalustalle. Kuten ehkä jo tiedät, kaikki metodin nimet esitetään camelCasedilla [2], kun taas C++- ja .NET-kehittäjät näkevät metodinimet PascalCased-muodossa [3]. Toinen radikaalimpi muutos on automaattinen kartoitus C++- ja .NET-rajapintojen välillä. Siksi. .NET-kehittäjien ei tarvitse käsitellä Windows.Foundation.Collections-nimiavaruutta, vaan jatkaa System.Collections.Generic-nimiavaruuden käyttöä. IVectorView<T>- ja IMapView<K, V>-rajapinnat muunnetaan ajonaikaisesti <T>IReadOnlyList-rajapinnoiksi ja IReadOnlyDictionary<TKey, TValue> liitännöiksi.
On syytä huomata, että nämä liitäntänimet C++/WinRT:ssä ovat jossain määrin tarkempia. Näitä rajapintoja käytetään esittämään joitakin kokoelman näkymiä, mutta rajapinta ei takaa, että kokoelma itsessään on muuttumaton. Jopa kokeneiden keskuudessa. Yleinen virhe .NET-kehittäjien keskuudessa on olettaa, että ReadOnlyCollection-tyyppi on kopio muuttumattomasta kokoelmasta, mutta todellisuudessa se on vain aktiivisen kokoelman kääre (katso Andrew Arnottin samanniminen kirjoitus saadaksesi lisätietoja vain luku-, pakastetuista ja muuttumattomista kokoelmista).
Vaikka <T>IList-rajapinnassa on samat jäsenet kuin IReadOnlyList-rajapinnassa <T>ja kaikki IList-tyyppiset <T>listat voidaan esittää vain luku -listoina, IList <T>ei peri IReadOnlyLististä<T>, mikä voi olla mielenkiintoista oppia. Immo Landwerth selitti,
Syynä siihen, että se toimii, on se, että nuo vain luku -rajapinnat ovat puhtaita luku-kirjoitusliitäntöjen osajoukkoja, mikä vaikuttaa järkevältä oletukselta. Valitettavasti tämä oletus ei vastaa todellisuutta, sillä jokaisella metatietotasolla jokaisella rajapinnan metodilla on oma paikkansa (mikä saa eksplisiittiset rajapinnan toteutukset toimimaan).
Toisin sanoen, ainoa mahdollisuus ottaa käyttöön vain luku -rajapinta muuttuvana luokkapohjana on palata . NET 2.0, eli silloin kun ne alun perin syntyivät. Kun se on täysin otettu käyttöön, ainoa muutos, jonka se voi tehdä, on lisätä kovariantteja ja/tai invertterimerkkejä (esitettynä "sisään" ja "ulos" VB:ssä ja C#:ssa).
Kun häneltä kysyttiin, miksi IReadOnlyCollection-rajapintaa ei <T>ole, Immo vastasi,
Harkitsimme tätä suunnittelua, mutta ajattelimme, että tyypin lisääminen, joka tarjoaisi vain Count-attribuutin, ei lisäisi juurikaan arvoa peruskirjastoon. Peruskirjastotiimissä uskomme, että jos API alkaa miinus 1000 pisteestä, edes jonkin verran arvoa ei riitä lisäämisen perustelemiseen. Uusien API-rajapintojen lisäämisen perusteluna on myös kustannus, esimerkiksi kehittäjillä on enemmän konsepteja valittavanaan. Aluksi ajattelimme, että tämän tyypin lisääminen parantaisi koodia tietyissä tilanteissa, joissa haluat vain laskea ja tehdä sillä jotain mielenkiintoista. Esimerkiksi laajenna massana olemassa olevaan kokoelmaan. Näissä tilanteissa olemme kuitenkin kannustaneet ihmisiä käyttämään vain <T>IEnumerable-rajapintaa ja <T>erityistapauksessa, jossa on instanssi, joka toteuttaa ICollection-rajapinnan. Koska kaikki sisäänrakennetut kokoelmatyypit toteuttivat tämän rajapinnan, näissä yleisimmissä tilanteissa suorituskyvyn parannusta ei ole saavutettu. Muuten, <T>IEnumerablen laajennusmenetelmä Count() voi tehdä tämän myös.
Nämä uudet rajapinnat ovat saatavilla . NET 4.5 ja . NET for Windows 8。
Käännösmuistiinpanot
[1] Perusluokan kirjasto, lyhennettynä BCL. Lisätietoja perusluokkakirjastosta saat osallistumalla MSDN-ohjelmaan.
[2] CamelCased, kyhmy-nimikkeistö, tunnetaan myös nimellä alempi kamel-kotelo. Muoto on, että ensimmäinen sana alkaa pienellä kirjaimella; Toisen sanan ensimmäinen kirjain on isolla kirjattu, esimerkiksi: etunimi, sukunimi.
[3] PascalCased, Pascal-nimistö, tunnetaan myös nimellä yläkamelin kotelo. Muoto on, että jokaisen sanan ensimmäinen kirjain on isolla kirjain, esimerkiksi: Etunimi, Sukunimi, CamelCase. |
Julkaistu 5.2.2018 14.28.10
|
|
|
