C # veya .Net özellikleri geriye dönük uyumluluk gerekmediğini varsayarak kesmek için? [kapalı]

Herhangi bir ürün veya çerçeve gelişir. Temel olarak kullanıcılarının ihtiyaçlarını yakalamak, yeni bilgi işlem güçlerinden yararlanmak ve daha iyi hale getirmek için yapılır. Bazen birincil tasarım hedefi ürünle de değişir. C # veya .net çerçevesi bir istisna değildir. Gördüğümüz gibi, günümüzün 4. versiyonu birincisine kıyasla çok farklı. Ancak şey, bu evrimsel geriye dönük uyumluluğa barikat olarak gelir.

Çerçevelerin / ürünlerin çoğunda geriye dönük uyumluluğu desteklemeye gerek olmasaydı özellikler kesilirdi. Size göre, C # /. Net bu özellikleri nelerdir?

Lütfen her cevap için bir özellik belirtin.

Anonim yöntemler . Herkes C # 2.0 için seçilen anonim yöntem sözdizimi, C # 3.0 için eklenen lambda sözdizimine göre tıknaz ve tıknaz olduğunu kabul eder. Aynı şeyi yapmak için neredeyse özdeş iki sözdizimine sahip olmak çok talihsiz bir durumdur.

Jenerik olmayan koleksiyonlardan kurtulurdum. Onlar bir iğrenç ... ve linq kullandığım ve böyle bir şey yapmak zorunda olduğum çok fazla vaka var

var customObjects = container.CustomObjects.Cast<CustomObject>();

Bunu her yaptığımda, ruhumun küçük bir kısmı ölür.

tür olarak geçersizdir . Neden "geçersiz" bir tür? Hiçbir örneği yoktur, değeri yoktur, genel tür argümanı, resmi parametre türü, yerel tür, alan türü veya özellik türü olarak kullanamazsınız. Bir tür olarak hiçbir anlamı yoktur; daha ziyade, bir yöntem çağrısının sanal makine yığını üzerinde ne gibi bir etkisi olduğu bir gerçektir . Ancak sanal makine sadece budur: sanal bir makine. Gerçek makine döndürülen değeri bir kayıt defterine koyar (genellikle x86'da EAX) ve yığını hiç etkilemez! Bir tür olarak geçersizlik sadece kötü bir fikirdir.

Daha kötüsü: bir işaretçi türünde kullanıldığında, dönüş türü olarak kullanıldığından tamamen farklı birvoid* şey ifade eder. Şimdi "bilinmeyen tipte bir depolama yerine bir işaretçi" anlamına gelir. Bu, "herhangi bir değer döndürmeyen bir yöntem" anlamıyla hiçbir ilgisi yoktur.

void*İşaretçi türü olarak değiştirebilirsiniz IntPtr. (Ve void**ile IntPtr*vb.) Biz, "Unit", tek bir değer, yani null adlı olan bir tür olan bir dönüş türü olarak void yerini alabilir. CLR'nin bir uygulaması daha sonra, bir birim tipi işlev çağrısının "döndürülen" null değerinin güvenli bir şekilde göz ardı edilebileceğini bilerek kayıt veya yığın kullanımını uygun şekilde optimize edebileceğine karar verebilir.

Böyle bir dünyada artık ayrı Func<A, R>ve Action<T>delegelere ihtiyacınız yok . Action<T>sadece Func<T, Unit>.

Boş ifade; . Hata eğilimli, neredeyse her zaman bir yazım hatasıdır ve size zaten ifade edilmeyen hiçbir ek anlam vermez {}.

Referans tip dizilerde güvensiz kovaryans . Typesafe kovaryans açıkken IEnumerable<T>, dizi kovaryans ihtiyacının en azından bir kısmı ortadan kalkmıştır. (Kovaryant salt okunur bir liste arayüzümüz olsaydı, buna hiç ihtiyacımız olmazdı.)

Tekli artı operatör . Tüm zamanların en az kullanışlı operatörü. Geriye dönük uyumluluk için tutmak zorunda olmasaydık, bir kalp atışında çıkarırdım. Kim bu şeyi kullanıyor?

(Açıklama: tekli artı işareti +xÖn artırma operatör değildir ++xdeğil, postincrement operatör x++olup ikili ek operatör x+y).

Sayısal değişmezleri varsayılan olarak double

Çoğu iş uygulaması için, decimalyine de daha uygundur ... veya belki de bir varsayılan fikri kaldırmak ve geliştiriciyi gerçekten seçim yapmaya zorlamak daha iyi olur .

(De bazı başka şeyler için uygun olacağını "varsayılan kaldırmak" Bu. Örneğin, ben sınıflar varsayılan olarak kapalı gerektiğini herkesi ikna etmeye çalışıyor vazgeçtiği, ama onlar gerektiğini insanları ikna etmek kolay şüpheli ettik düşünüyorum yaklaşık yeni sınıflarının mühürlenmesi gerekip gerekmediği ve açıkça belirtilmesi).

Bu, bir özellikten daha çok bir kılavuzdur, ancak bence bu önemli çünkü kanonik ve en iyi çözüm olarak insanların zihninde zaten çok fazla kökleşmiş:

Resmi desen uygulamak IDisposable.

Bu hantal ve daha iyi yollar var .

Çeşitli zamanlayıcı sınıfları arasında büyük farklılıklar olduğunu biliyorum . Ama yine de bir veya iki tanesinden kurtulamadık mı?

Yöntem ve türleri Arrayve List<T>bu örneğin, Linq ile demode olmadan:

• Array.TrueForAll ile değiştirilebilir Enumerable.All
• Array.FindAll ile değiştirilebilir Enumerable.Where
• List<T>.ConvertAll ile değiştirilebilir Enumerable.Select
• Predicate<T> ile değiştirilebilir Func<T, bool>
• Converter<T,R> ile değiştirilebilir Func<T, R>
• IComparer<T> gerçekten bir temsilci olmalı Func<T, T, int>

Jenerik Olmayan Delegeler Jenerik olmayan koleksiyonlar gibi jenerik olmayan delegeler de artık Func ve Action serisine sahip olduğumuz için işe yaramaz. Ve üç parametrede varyantları keserdim. Üçten fazla parametreniz varsa, bir yapı oluşturun ve bunu tek parametre olarak kullanın. Olay işleme için belirli bir delege bildirmek çok KURU değil.

asmx Web Hizmetleri

Bence günümüzde WCF ile oldukça eski.

Winforms
İki masaüstü platformu arasında gezinmek zorunda değilsiniz. WPF, işlerin gittiği yerdir, bu nedenle platform düzeyinde yedekliliğe sahip olmak sinir bozucu.