.NET 4.5İki yeni koleksiyon arayüzü, IReadOnlyList ve IReadOnlyDictionary eklendi. Bu arayüzler yüzeyde çok sıradan görünse de, geriye dönük uyumluluk, birlikte çalışabilirlik ve birlikte değişebilirliğin rolü hakkında oldukça karmaşık hikayeler ortaya koyuyor.
IReadOnlyList ve IReadOnlyDictionary, .NET geliştiricilerinin her zaman sahip olmak istediği iki arayüzdür. Yazılabilir arayüzlerin aksine, yalnızca okunan bir arayüz, yalnızca NotSupportedException istisnasını atan ve hiçbir şey yapmayan yöntemlerin uygulanmasını ortadan kaldırmalıdır. Tüm bunlar zaman kısıtlamaları nedeniyle tamamlanmadı.
Bir sonraki fırsat geldi. NET 2.0. Bu, Microsoft'un zayıf tipli koleksiyonları emekliye kaldırıp güçlü tipli eş koleksiyonlarıyla değiştirmesini sağlar. Ancak, üs kütüphanesi[1] ekibi bir kez daha yalnızca okunabilir bir liste sunma fırsatını kaçırdı; Kit George şöyle yazdı:
Joe ile bahsettiğiniz sorun için varsayılan bir uygulama sunmayı amaçladığımız için, arayüz vermek yerine ReadOnlyCollectionBase temel sınıfını sunuyoruz. Ancak, insanların güçlü bir tür olmadığı için kullanmakta isteksiz olmasını anlayabiliyorum. Ama jenerik ürünlerin tanıtılmasıyla artık ReadOnlyCollection da var<T>, böylece sadece aynı işlevselliği değil, aynı zamanda güçlü bir tür: harika!
ReadOnlyCollection <T>mühürlü bir sınıf olmadığından, gerekirse kendi koleksiyonunuzu tam hızda yazabilirsiniz. Bu amaçla oluşturduğumuz koleksiyonlar genel ihtiyaçlara uyarlanabilir olduğundan, aynı konsept için arayüzler eklemeyi planlamıyoruz.
Krzysztof Cwalina da bu konudaki görüşünü şöyle dile getirdi:
Kulağa şaşırtıcı gelse de, IList ve IList <T>sadece okunabilir koleksiyonlar için kullanmayı planladığımız iki arayüz. Her ikisi de IsReadOnly boolean özelliğine sahiptir; bu özellik, yalnızca okunan bir koleksiyon bu özelliği uyguladığında true döndürmelidir. Tamamen okunabilir bir arayüz eklemek istemememizin nedeni, temel kütüphaneye gereksiz karmaşıklık kattığını düşünmemiz. Karmaşıklık açısından hem bu yeni arayüzü hem de tüketicilerini ifade ediyoruz.
API tasarımcısının IsReadOnly özelliğini çalışma zamanında kontrol etmekten ve ortaya çıkabilecek istisnalardan etkilenmediğine inanıyoruz; bu durumda IList arayüzünü kullanmanın sorun olmadığını düşünüyoruz; Eğer tek seferde gerçekten temiz bir özel API sunmaya istekliyse, bu durumda IList arayüzünün uygulanmasını göstermeli ve özel bir okunabilir API yayımlamalılar. İkincisi, nesne modelinden maruz kalan koleksiyonlar için tipiktir.
Geliştiriciler bu durumdan şikayet etse de, jenerik ürünlerin sunduğu yeni fırsatlar bu temel noktayı çok daha bastırıyor ve sorun şu durumda. NET 4 daha önce büyük ölçüde görmezden gelindi. Ancak bu karar bazı tepkileri de tetikledi ve bunları daha sonra konuşacağız.
İçeri var. .NET 4'te heyecan verici yeni bir özellik çalışma zamanına eklendi. Daha önceki bir versiyonda. .NET, arayüzler tipe dönüştüğünde, bu arayüzler aşırı kısıtlanır. Örneğin, Müşteri Person'dan miras alsa bile, IEnumerable tipindeki bir <Customer>nesneyi parametre olarak IEnumerable tipindeki bir fonksiyona aktarmak mümkün değildir<Person>. Kovaryant desteğin eklenmesiyle bu kısıtlama kısmen kaldırıldı.
"Kısmen" diyoruz çünkü bazı durumlarda insanlar IEnumerable bir arayüz kullanmak yerine zengin bir API'ye sahip bir arayüzü aynı anda kullanmalı. IList arayüzü kovariant olmasa bile, yalnızca okunabilir bir liste arayüzü olmalıdır. Ne yazık ki, . .NET baz kütüphane ekibi yine bu eksikliği ele almamaya karar verdi.
Sonra WinRT'nin tanıtımı ve COM'un geri dönüşü her şeyi değiştirdi. COM birlikte çalışabilirliği bir zamanlar geliştiricilerin başka seçenekleri kalmadığında kullandığı bir teknolojiydi, ancak şimdi bir . .NET programlamanın temel taşı. Ve WinRT, IVectorView <T>ve IMapView<K arayüzlerini açığa çıkardığı için, V> arayüzlerini ortaya koyar. .NET de buna göre ayarlanmalıdır.
WinRT programının ilginç bir özelliği, her geliştirme platformu için farklı ama benzer API'lerin duyurulmasıdır. Bildiğiniz gibi, tüm metod isimleri camelCased [2] ile temsil edilirken, C++ ve .NET geliştiricileri metod isimlerini PascalCased [3] olarak görür. Daha radikal bir diğer değişiklik ise C++ ve .NET arayüzleri arasındaki otomatik eşlemedir. Bu nedenle. .NET geliştiricileri Windows.Foundation.Collections isim alanıyla uğraşmak zorunda değil, sadece System.Collections.Generic isim alanını kullanmaya devam etmelidir. IVectorView <T>ve IMapView<K, V> arayüzleri çalışma zamanı tarafından sırasıyla IReadOnlyList <T>ve IReadOnlyDictionary<TKey, TValue> arayüzlerine dönüştürülecek.
C++/WinRT'deki bu arayüz isimlerinin bir dereceye kadar daha doğru olduğunu belirtmek gerekir. Bu arayüzler, bir koleksiyonun bazı görünümlerini temsil etmek için kullanılır, ancak arayüz koleksiyonun kendisinin değiştirilemez olmasını garanti etmez. Deneyimli olanlar arasında bile. .NET geliştiricileri arasında yaygın bir hata, ReadOnlyCollection tipinin değişmez bir koleksiyonun kopyası olduğunu varsaymaktır; ancak aslında sadece aktif bir koleksiyon için bir wrapper (yalnızca okunabilir, dondurulmuş ve değiştirilemez koleksiyonlar hakkında daha fazla bilgi için Andrew Arnott'un aynı adlı gönderisine bakınız).
IList <T>arayüzü, IReadOnlyList arayüzüyle aynı üyelere <T>sahip olsa da ve tüm IList tipi <T>listeler yalnızca okunabilir listeler olarak temsil edilebilse de, IList <T>IReadOnlyList'ten miras almaz <T>ve bu hakkında bilgi edinmek ilginç olabilir. Immo Landwerth şöyle açıkladı,
Çalışmasının sebebi, bu sadece okunan arayüzlerin tamamen okuma-yazma arayüzlerinin alt kümeleri olmasıdır ki bu makul bir varsayım gibi görünüyor. Ne yazık ki, bu varsayım gerçeklikle örtüşmüyor, çünkü meta veri seviyesinde her arayüzdeki her yöntemin kendi yuvası vardır (bu da açık arayüz uygulamalarının çalışmasını sağlar).
Başka bir deyişle, yalnızca okunabilir bir arayüzü değişken sınıf temel sınıfı olarak tanıtmanın tek yolu 'ya geri dönmektir. NET 2.0, yani ilk tasarlandıkları zaman. Tam olarak yayımlandıktan sonra, yapabileceği tek değişiklik kovaryant ve/veya invertör işaretleyicileri eklemek (VB ve C#'da "in" ve "out" olarak gösterilir).
IReadOnlyCollection arayüzü neden olmadığı <T>sorulduğunda, Immo şöyle yanıtladı:
Bu tasarımı düşündük, ancak sadece Count özelliğini sağlayan bir tür eklemenin temel kütüphaneye çok fazla değer katmayacağını düşündük. Temel kütüphane ekibinde, bir API eksi 1000 ile başlarsa, biraz değer vermek bile eklenmek için yeterli olmayacağını düşünüyoruz. Yeni API'ler eklemenin gerekçesi ayrıca bir maliyet de içerir; örneğin, geliştiricilerin seçebileceği daha fazla kavram olur. Başta, bu tipi eklemenin, sadece bir sayı almak ve sonra ilginç bir şey yapmak istediğiniz bazı durumlarda kodun daha iyi performans göstereceğini düşündük. Örneğin, mevcut bir koleksiyona toplu katkı yap. Ancak bu senaryolarda, insanları yalnızca IEnumerable <T>arayüzü kullanmaya teşvik ettik ve <T>ICollection arayüzünü uygulayan özel bir örnek için de bulunduk. Tüm yerleşik koleksiyon türlerimiz bu arayüzü uyguladığından beri, en yaygın senaryolarda performans artışı olmadı. Bu arada, <T>IEnumerable için Count() uzatma yöntemi de bunu yapabilir.
Bu yeni arayüzler için mevcuttur. NET 4.5 ve . NET for Windows 8。
Çeviri notları
[1] Temel Sınıf Kütüphanesi, kısaltma olarak BCL. Temel sınıf kütüphanesi hakkında daha fazla bilgi için lütfen MSDN'ye katılın.
[2] CamelCased, hump isimleri, ayrıca alt deve kasası olarak da bilinir. Biçim şudur: ilk kelime küçük harfle başlar; İkinci kelimenin ilk harfi büyük harfle yazılır, örneğin: FirstName, FamilyName.
[3] Pascal Case, Pascal isimlendirmesi, üst deve kasası olarak da bilinir. Biçim şudur: Her kelimenin ilk harfi büyük harfle yazılır, örneğin: FirstName, LastName, CamelCase. |
Yayınlandı 5.02.2018 14:28:10
|
|
|
