C # (.NET) Tasarım Kusurları [kapalı]

Genel olarak C # veya .NET Framework'teki en büyük tasarım kusurlarından bazıları nelerdir?

Örnek: boş değer atanamaz bir dize türü yoktur ve bir IDataReader'dan değerleri alırken DBNull'u kontrol etmeniz gerekir.

Bu gönderiye kesinlikle katılıyorum (ToString eksikliğini dışlayanlar için, sınıfınız için özel bir format sağlamak için bir hata ayıklayıcı özelliği vardır).

Yukarıdaki listenin üstüne, aşağıdaki makul istekleri de eklerim:

1. null yapılabilir değer türlerinin tamamlayıcısı olarak null yapılamayan başvuru türleri,
2. bir yapının boş yapıcısının geçersiz kılınmasına izin verin,
3. genel tür kısıtlamalarının mühürlenmiş sınıfları belirtmesine izin verin,
4. Kısıtlama olarak kullanıldığında keyfi kurucu imzaları talep eden başka bir postere katılıyorum, yani. nerede T : new(string)veya neredeT : new(string, int)
5. Ayrıca, hem boş olay listeleri hem de eşzamanlı ortamda olayların düzeltilmesi hakkında başka bir postere katılıyorum (ikincisi zor olsa da),
6. operatörler sınıfın statik metotları olarak değil (veya en azından sadece statik metotlar olarak değil) genişletme metotları olarak tanımlanmalıdır,
7. arayüzler için statik özelliklere ve yöntemlere izin verin (Java'da buna sahiptir, ancak C # yoktur),
8. nesne başlatıcılarda olay başlatmaya izin ver (şu anda yalnızca alanlara ve özelliklere izin verilmektedir),
9. "nesne başlatıcı" sözdizimi neden yalnızca bir nesne oluştururken kullanılabilir? Neden herhangi bir zamanda kullanıma sunmuyorsunuz, yani.var e = new Foo(); e { Bar = baz };
10. ikinci dereceden numaralandırılabilir davranışı düzeltmek ,
11. tüm koleksiyonların yineleme için değişmez anlık görüntüleri olmalıdır (yani, koleksiyonun değiştirilmesi yineleyiciyi geçersiz kılmamalıdır),
12. Tuplelar eklemek kolaydır, ancak " Either<T>" gibi verimli bir kapalı cebirsel tip değildir, bu nedenle kapalı bir cebirsel tip beyan etmenin ve üzerinde kapsamlı desen eşleştirmesinin uygulanmasının bir yolunu çok isterim (temelde ziyaretçi modeli için birinci sınıf destek, ancak çok daha verimli); bu nedenle yalnızca numaralandırmaları alın, kapsamlı kalıp eşleştirme desteğiyle genişletin ve geçersiz vakalara
13. Genel olarak örüntü eşleştirmeyi desteklemek isterdim, ancak en azından nesne türü testi için; Ayrıca burada başka bir gönderide önerilen anahtar sözdizimini de beğeniyorum,
14. System.IOSınıfların Streambiraz kötü tasarlandığına dair başka bir gönderiye katılıyorum ; bazı uygulamaların atılmasını gerektiren herhangi bir arayüz NotSupportedExceptionkötü bir tasarımdır,
15. IListolduğundan çok daha basit olmalı; aslında, bu gibi beton toplama arayüzleri çoğu için doğru olabilir ICollection,
16. örneğin IDictionary gibi çok fazla yöntem istisnalar atar,
17. Java'da mevcut olandan daha iyi bir tür kontrol edilmiş istisna tercih ederim (bunun nasıl yapılacağı için tür ve etki sistemleri araştırmasına bakın),
18. genel yöntem aşırı yük çözümlemesinde çeşitli can sıkıcı köşe durumlarını düzeltin; örneğin, biri başvuru türlerinde, diğeri null yapılabilir yapı türlerinde çalışan iki aşırı yüklenmiş uzantı yöntemi sağlamayı deneyin ve tür çıkarımınızın bunu nasıl sevdiğini görün,
19. INotifyPropertyChangedalan adını bir dizge olarak alan gibi arabirimler için alan ve üye adlarını güvenli bir şekilde yansıtmanın bir yolunu sağlar ; Bunu, lambda'yı a MemberExpression, ie ile alan bir genişletme yöntemi kullanarak yapabilirsiniz . () => Foo, ancak bu çok verimli değil
    • Güncelleme: C # 6.0 nameof(), tek üye adları için işleci ekledi , ancak jeneriklerde çalışmıyor ( nameof(T) == "T"gerçek tür bağımsız değişkeninin adı yerine: yine de yapmanız gerekiyor typeof(T).Name) - ne de bir "yol" dizesi almanıza izin vermiyor , örneğin nameof(this.ComplexProperty.Value) == "Value"olası uygulamalarını sınırlama.
20. arabirimlerde operatörlere izin verin ve tüm çekirdek numara türlerini uygulayın IArithmetic; diğer kullanışlı paylaşımlı operatör arayüzleri de mümkündür,
21. nesne alanlarının / özelliklerinin değiştirilmesini zorlaştırın veya en azından, değişmez alanlara açıklama eklemeye izin verin ve tür denetleyicinin onu zorlamasını sağlayın (sadece hatıra özelliği olarak davranın, çünkü bu zor değil!); aslında, alanları ve özellikleri daha mantıklı bir şekilde birleştirin çünkü ikisine birden sahip olmanın bir anlamı yok; C # 3.0'ın otomatik özellikleri bu yöndeki ilk adımdır, ancak yeterince ileri gitmezler,
    • Güncelleme: C # readonlyanahtar kelimesine sahipken ve C # 6.0 salt okunur otomatik özellikler eklerken, değişmez türler ve değerler için gerçek dil desteği kadar katı değildir.
22. yapıcıları bildirmeyi basitleştirin; F # 'ın yaklaşımını seviyorum, ancak buradaki sınıf adı yerine basitçe "yeni" gerektiren diğer gönderi en azından daha iyi,

Sanırım şimdilik bu kadar yeter. Bunların hepsi geçen hafta karşılaştığım rahatsızlıklar. Gerçekten aklımı koyarsam muhtemelen saatlerce devam edebilirim. C # 4.0 zaten kesinlikle onayladığım adlandırılmış, isteğe bağlı ve varsayılan bağımsız değişkenler ekliyor.

Şimdi mantıksız bir istek için:

1. o olurdu , gerçekten, gerçekten C # / CLR yani cinsi yapıcı polimorfizm ve destek olabilir güzel. jenerikler üzerinde jenerikler,

Güzel lütfen? :-)

• Reset()üzerinde yöntem IEnumerator<T>yineleyici blokları, dilin Spec için bile bir hata (idi talepler bu bir istisna atar)
• dizileri döndüren yansıma yöntemleri Eric'in görüşüne göre bir hataydı
• dizi kovaryansı bir tuhaflıktı ve kalır
  • Güncelleştirme: .NET 4.0 ile C # 4.0, genel arabirimlere ortak değişken / kontravaryans desteği ekledi (gibi IEnumerable<out T>ve Func<in T, out TResult>ancak somut türler (gibi List<T>) değil.
• ApplicationException yerine gözden düştü - bu bir hata mıydı?
• senkronize koleksiyonlar - güzel bir fikir, ancak gerçekte yararlı olması gerekmez: genellikle birden çok işlemi senkronize etmeniz gerekir ( Containsdaha sonraAdd ), bu nedenle farklı işlemleri senkronize eden bir koleksiyon o kadar da kullanışlı olmaz
  • Güncelleme: tipleri ile , , vb .NET Framework 4.0 eklendi - fabrika temsilci kabul yöntemler fabrika sadece anahtar başına bir kere çağrılır garanti etmez bile.System.Collections.ConcurrentTryAddGetOrAddTryRemove
• using/ lockşablonundan daha fazla yararlanılabilirdi - belki de yeniden kullanılabilir (genişletilebilir?) bir sözdizimini paylaşmalarına izin verebilirdi; bunu geri dönerek IDisposableve kullanarak simüle edebilirsiniz using, ancak daha net olabilirdi
• yineleyici bloklar: argümanları önceden kontrol etmenin basit bir yolu yoktur (tembellikten ziyade). Elbette, iki zincirleme yöntem yazabilirsiniz, ancak bu çirkin
• daha basit değişmezlik iyi olurdu; C # 4.0 biraz yardımcı olur , ancak yeterli değildir
• hayır "bu ref-tipi parametre boş olamaz" desteği - ancak sözleşmeler (4.0'da) bu konuda yardımcı olur. Ancak sözdizimi Foo(SqlConnection! connection)(boş bir kontrol / ekleyen throw) güzel olurdu ( int?vb. Aksine )
  • Güncelleme: Bu, C # 8.0'da düzeltilmiştir .
• operatörlerin ve varsayılan olmayan kurucuların jeneriklerle desteklenmemesi; C # 4.0 çözer bununla biraz dynamicya da etkinleştirebilirsiniz böyle
• yineleyici değişkeni , genişletme sırasında süre dışında bildirilir foreach, yani anon-methodlar / lambdas, her yineleme için bir değişken yerine tek bir değişkeni yakalar (threading / async / etc ile ağrılı)
  • Güncelleme: Bu, C # 5.0 ile düzeltildi .

TextWriter a, temel StreamWriter'ın sınıfıdır. o ne lan?

Bu her zaman beni aşırı derecede karıştırır.

Küçük bir C # pet peev - oluşturucular, oluşturucunun sınıfla aynı ada sahip olması için C ++ / Java sözdizimini kullanır.

New()ya ctor()da çok daha güzel olurdu.

Ve elbette, coderush gibi araçlar, sınıfları yeniden adlandırmak için bunu daha az sorun haline getirir, ancak okunabilirlik bakış açısıyla, New () büyük bir netlik sağlar.

Yapamayacağını anlamıyorum

burada T: yeni (U)

Yani genel tip T'nin varsayılan olmayan bir kurucuya sahip olduğunu bildirirsiniz.

Düzenle:

Bunu yapmak istiyorum:

public class A 
{
    public A(string text) 
    {

    }
}


public class Gen<T> where T : new(string text) 
{

}

Bundan ilk bahseden ben olduğuma gerçekten şaşırdım:

ADO.NET türlenmiş veri kümeleri, null yapılabilir türlerin özellikleri olarak null yapılabilir sütunları göstermez. Bunu yazabilmelisin:

int? i = myRec.Field;
myRec.Field = null;

Bunun yerine şunu yazmalısın ki bu çok aptalca:

int? i = (int?)myRec.IsFieldNull() ? (int?)null : myRec.Field;
myRec.SetFieldNull();

Bu, .NET 2.0'da can sıkıcıydı ve güzel, düzgün LINQ sorgularınızda yukarıdaki gibi jiggery-pokery kullanmak zorunda olmanız şimdi daha da can sıkıcı.

Ayrıca, üretilen Add<TableName>Rowyöntemin null atanabilir türler kavramına benzer şekilde duyarsız olması da can sıkıcı . Her şey, oluşturulduğundan beriTableAdapter yöntemler öyle değil.

.NET'te geliştirme ekibinin "Tamam çocuklar, yeterince yakınız - gönderin!" Dediğini hissettiren pek bir şey yok. Ama bu kesinlikle öyle.

1. Stream, StringWriter, StringReader, TextReader, TextWriter sınıflarının büyük bir hayranı değilim ... neyin ne olduğu sezgisel değil.
2. IEnumerable.Reset yineleyiciler için bir istisna atma. Veritabanına bağlandığında her zaman sıfırlamayı çağıran bazı üçüncü taraf bileşenlerim var, bunları kullanmak için önce bir listeye yayınlamamı gerektiriyor.
3. Xml Serializer, seri hale getirilmiş IDictionary öğelerine sahip olmalıdır
4. HttpWebRequest & FTP API'yi tamamen unutmuşum, benim için ne acı .... (Nicholas'ın bana bunu hatırlatması için teşekkürler :-)

Edit
5. Benim bir başka sıkıntım da System.Reflection.BindingFlags'ın kullandığınız yönteme bağlı olarak farklı kullanımları olmasıdır. Örneğin FindFields'da CreateInstance veya SetField ne anlama geliyor? Bu, kafa karıştırıcı olan bu sayımın arkasındaki anlamı aşırı yükledikleri bir durum.

Bunun bir tasarım hatası olduğunu söyleyecek kadar ileri gideceğimi bilmiyorum, ancak VB'de yapabildiğiniz gibi bir lambda ifadesini çıkarırsanız gerçekten güzel olurdu:

VB:

Dim a = Function(x) x * (x - 1)

C #

Bunu yapabilsem güzel olurdu:

var a = x => x * (x - 1);

Bunu yapmak zorunda kalmak yerine:

Func<int, int> a = x => x * (x - 1);

Çok uzun sürmediğinin farkındayım, ama Code Golf'te her karakterin önemi var! Bu programlama dillerini tasarlarken bunu hesaba katmıyorlar mı? :)

1. System.Object sınıfı:

   • Eşittir ve GetHashCode - tüm sınıflar karşılaştırılabilir veya karma hale getirilemez, bir arabirime taşınmalıdır. IEquatable veya IComparable (veya benzeri) akla geliyor.

   • ToString - tüm sınıflar bir dizeye dönüştürülemez, bir arabirime taşınmalıdır. IFormattable (veya benzeri) akla geliyor.

2. ICollection.SyncRoot özelliği:

   • Kötü tasarımı teşvik eder, harici bir kilit neredeyse her zaman daha kullanışlıdır.

3. Jenerikler başından beri orada olmalıydı:

   • System.Collections ad az ya da çok eskimiş sınıflar ve arayüzler bir sürü içerir.

Beni rahatsız eden şeylerden biri Predicate<T> != Func<T, bool>paradoks. İkisi de türden delege T -> boolama yine de atama uyumlu değiller.

Bazı insanlar (ISV'ler) dotNet çalışma zamanına ihtiyaç duymayan yerel bir yürütülebilir dosya oluşturmak için derleme zamanında makine koduna derleyebilmenizi ve onu bağlamanızı ister.

Doğru OO teknikleri hakkında çok şey biliyoruz . Ayrıştırma, sözleşmeyle programlama, uygunsuz kalıtımdan kaçınma, istisnaların uygun kullanımı, açık / kapalı yönetici, Liskov ikame edilebilirliği vb. Henüz hiçbiri, .Net çerçeveleri en iyi uygulamaları kullanmamaktadır.

Bana göre .Net tasarımındaki en büyük kusur, devlerin omuzlarında durmak değil; Çerçevelerini kullanan programcı kitlelerine ideal programlama paradigmalarından daha azını tanıtmak .

MS buna dikkat etseydi, yazılım mühendisliği dünyası bu on yılda kalite, kararlılık ve ölçeklenebilirlik açısından büyük sıçramalar yapabilirdi, ancak ne yazık ki geriliyor gibi görünüyor.

C # switch deyimini beğenmedim.

Bunun gibi bir şey isterim

switch (a) {
  1    : do_something;
  2    : do_something_else;
  3,4  : do_something_different;
  else : do_something_weird; 
}

Böylece artık kesintiler (unutulması kolay) ve farklı değerleri virgülle ayırma imkanı yok.

Dinleyicileri açıkça kontrol etmeniz gereken C # olayları. Olayların amacı, orada olanlara yayınlamak değil miydi? Hiç olmasa bile?

İç içe / yinelemeli yineleyicilerin korkunç (ve çoğu insan için oldukça görünmez) O (N ^ 2) davranışı .

Bu konuyu bildikleri, nasıl düzelteceklerini bildikleri için oldukça üzgünüm, ancak dahil olmayı hak etmek için yeterli önceliğe sahip olarak görülmüyor.

Her zaman ağaç benzeri yapılarla çalışıyorum ve aksi takdirde akıllı insanların kodunu, yanlışlıkla bu şekilde çok pahalı işlemler başlattıklarında düzeltmek zorundayım.

"Getiri foreach" in güzelliği, daha basit, daha kolay sözdiziminin doğru, performanslı kodu teşvik etmesidir. Bu, platformun uzun vadeli başarısı için yeni özellikler eklemeden önce hedeflemeleri gerektiğini düşündüğüm "başarı çukuru" dur.

Bazı sınıflar arabirimler uygular ancak bu arabirimin birçok yöntemini uygulamazlar, örneğin Array IList'i uygular ancak 9 yöntemden 4'ü NotSupportedException http://msdn.microsoft.com/en-us/library/system.array_members .aspx

Arabirimlerdeki statik üyeler ve iç içe geçmiş türler.

Bu, özellikle bir arayüz üyesi arayüze özgü bir parametreye ( örneğin, bir enum) sahip olduğunda faydalıdır . Numaralandırma türünü arabirim türüne yerleştirmek güzel olurdu.

Olayların son derece tehlikeli varsayılan doğası. Bir etkinliği arayabilmeniz ve kaldırılan aboneler nedeniyle tutarsız bir durumda olabilmeniz gerçekten korkunç. Bkz Jon Skeet en ve Eric Lippert en konuda daha fazla okuma için mükemmel makaleler.

• null her yerde.

• const Hiçbir yerde.

• API'ler tutarsızdır, örneğin bir dizi dönüşünü mutasyona uğratmak, voidancak bir diziye eklemek StringBufferaynı değişebilir StringBuffer.

• Toplama arayüzleri, değişmez veri yapılarıyla uyumsuzdur, örneğin Add, System.Collections.Generic.IList<_>bir sonuç döndüremez.

• Yapısal yazım yok, bu yüzden System.Windows.Media.Effects.SamplingMode.Bilinearsadece yazmak yerine yazarsınız Bilinear.

• Değişken IEnumeratorbir değişmez olması gerektiği zaman arayüz sınıfları tarafından uygulanan struct.

• Eşitlik ve karşılaştırma bir karmaşa: Elinizdeki System.IComparableve Equalsancak o zaman da var System.IComparable<_>, System.IEquatable, System.Collections.IComparer, System.Collections.IStructuralComparable, System.Collections.IStructuralEquatable, System.Collections.Generic.IComparerve System.Collections.Generic.IEqualityComparer.

• Tuplelar yapılar olmalıdır, ancak yapılar kuyruk çağrılarının ortadan kaldırılmasını gereksiz yere engeller, böylece en yaygın ve temel veri türlerinden biri gereksiz yere ayırır ve ölçeklenebilir paralelliği bozar.

0 enum olarak ayışığı

enum özellikleri: http://blogs.msdn.com/abhinaba/archive/2007/01/09/more-peculiarites-of-enum.aspx

bu iyi örnekte gösterildiği gibi: http://plus.kaist.ac.kr/~shoh/postgresql/Npgsql/apidocs/Npgsql.NpgsqlParameterCollection.Add_overload_3.html

benim önerim, "@" işaretini iyi bir şekilde kullanın:

onun yerine:

eğer ((myVar & MyEnumName.ColorRed)! = 0)

bunu kullan:

eğer ((myVar & MyEnumName.ColorRed)! = @ 0)

Başkaları tarafından zaten yapılmış olan uzun iyi noktalar listesine eklemek için:

• DateTime.Now == DateTime.Now çoğu durumda, ancak her durumda değil.

• StringDeğişmez olan, yapım ve manipülasyon için bir dizi seçeneğe sahiptir, ancak StringBuilder(değiştirilebilir olan) yoktur.

• Monitor.Enterve Monitor.Exitörnek yöntemler olmalıydı, bu nedenle belirli bir nesneyi kilitlemek için yenileştirmek yerine, onu yenileyebilir Monitorve kilitleyebilirsiniz.

• Yıkıcılar asla yıkıcı olarak adlandırılmamalıydı. ECMA spesifikasyonu, C ++ kalabalığı için çok daha az kafa karıştırıcı olan, bunlara sonlandırıcılar diyor, ancak dil spesifikasyonu hala onları yıkıcı olarak gösteriyor.

Özellikleri kullanma şeklimiz bazen beni rahatsız ediyor. Bunları Java'nın getFoo () ve setFoo () yöntemlerinin eşdeğeri olarak düşünmeyi seviyorum. Ama değiller.

Eğer Mülkiyet Kullanım Yönergeleri seri çalışabilir böylece özellikler gerekir devlet, herhangi bir sırada ayarlanması o zaman onlar sizsiniz, setter zamanlı doğrulama için yararsız. Bir nesnenin kendisinin geçersiz bir duruma geçmesine izin vermesini önlemek istediğiniz bir arka plandan geliyorsanız, özellikler sizin çözümünüz değildir. Bazen bu yüzden biz şeyin türden şeyler sınırlı yetkiye beri, kamu üyelerine daha iyi ne kadar görmek için başarısız gerekiyordu .

Bu amaçla, mülkiyet sözdizimini bir şekilde genişletebilmeyi her zaman diledim (bu çoğunlukla burada yüksek sesle düşünmektir, keşke böyle bir şey yapabilseydim). Bunun gibi bir şey hayal edin:

private string password;

public string Password
{
    // Called when being set by a deserializer or a persistence
    // framework
    deserialize
    {
       // I could put some backward-compat hacks in here. Like
       // weak passwords are grandfathered in without blowing up
       this.password = value;
    }
    get
    {
       if (Thread.CurrentPrincipal.IsInRole("Administrator"))
       {
           return this.password;
       }
       else
       {
           throw new PermissionException();
       }
    }
    set
    {
       if (MeetsPasswordRequirements(value))
       {
           throw new BlahException();
       }
       this.password = value;
    }
    serialize
    {
        return this.password;
    }
}

Bunun yararlı olup olmadığından veya bunlara erişmenin nasıl görüneceğinden emin değilim. Ama keşke özelliklerle daha fazlasını yapabilmeyi ve onlara gerçekten get ve set yöntemleri gibi davranabilmeyi diliyorum.

Genişletme yöntemleri güzeldir, ancak mixins konusunda gerçek karışımlarla daha temiz bir şekilde çözülebilecek sorunları çözmenin çirkin bir yoludur (neden bahsettiğimi görmek için Ruby'ye bakın). Bunları dile eklemenin gerçekten güzel bir yolu, jeneriklerin kalıtım için kullanılmasına izin vermek olurdu. Bu, mevcut sınıfları güzel bir nesne yönelimli şekilde genişletmenize olanak tanır:

public class MyMixin<T> : T
{
    // etc...
}

bu, örneğin bir dizeyi genişletmek için şu şekilde kullanılabilir:

var newMixin = new MyMixin<string>();

Uzatma yöntemlerinden çok daha güçlüdür çünkü yöntemleri geçersiz kılmanıza izin verir, örneğin bunları dil içinde AOP benzeri işlevselliğe izin verecek şekilde sarmalamak için.

Söz için özür dilerim :-)

Microsoft, çerçevedeki bariz hataları düzeltmeyecek ve son kullanıcıların bunları düzeltebilmesi için kancalar sağlamayacaktır.

Ayrıca, çalıştırılabilir .NET çalıştırılabilir dosyalarını çalışma zamanında ikili yama yapmanın bir yolu yoktur ve yerel kitaplıklara ikili yama uygulamadan (yükleme çağrısını kesmek için) .NET çerçeve kitaplıklarının özel sürümlerini belirtmenin bir yolu yoktur ve ILDASM yeniden dağıtılamaz, bu yüzden otomatikleştiremiyorum yine de yama.

• Boş değişken üzerinde bir uzantı yöntemini çağırabilmek tartışılabilir örn.

  nesne a = boş; a.MyExtMethod (); // bu çağrılabilir, bir yerde MyExtMethod'u tanımladığını varsayın

  Kullanışlı olabilir, ancak boş referans istisna konularında belirsizdir.

• Bir 'kusur' adlandırma. System.configuration.dll dosyasındaki "yapılandırma" nın 'C'si büyük harfle yazılmalıdır.

• İstisna işleme. İstisna zorla yakalanmalı veya Java'da olduğu gibi fırlatılmalıdır, derleyici derleme zamanında kontrol etmelidir. Kullanıcılar, hedef çağrı içindeki istisna bilgileri için yorumlara güvenmemelidir.

Çerçevenin V1'indeki SqlCommand üzerindeki .Parameters.Add () yöntemi korkunç bir şekilde tasarlandı - 0 değerine (int) sahip bir parametreyi geçerseniz, aşırı yüklerden biri temelde çalışmazdı - bu onların yaratmasına yol açtı SqlCommand sınıfındaki .Parameters.AddWithValue () yöntemi.

1. Hiçbir alt kümeleri vardır ICollection<T>ve IList<T>; en azından, bir kovaryant salt okunur koleksiyon arayüzü IListSource<out T>(bir numaralandırıcı, indeksleyici ve Sayım ile) son derece yararlı olurdu.
2. .NET, zayıf temsilcileri desteklemez . Geçici çözümler en iyi ihtimalle beceriksizdir ve dinleyici tarafı geçici çözümler kısmi güven içinde imkansızdır (ReflectionPermission gereklidir).
3. Genel arayüz birleştirmesi, mantıklı olsa ve hiçbir soruna neden olmasa bile yasaktır .
4. C ++ 'dan farklı olarak, ortak değişken dönüş türlerine .NET'te izin verilmez.
5. Eşitlik için iki değer türünü bit bazında karşılaştırmak mümkün değildir. İşlevsel " kalıcı " bir veri yapısında, birTransform(Sequence<T>, Func<T,T>) işlevin aynı değeri mi yoksa farklı bir değeri mi döndürdüğünü hızlı bir şekilde belirlemek için gereken işlevi . İşlev, argümanlarının çoğunu / tamamını değiştirmezse, çıktı dizisi giriş dizisindeki belleğin bir kısmını / tamamını paylaşabilir. Herhangi bir T tipini bit bazında karşılaştırma yeteneği olmadan, performansı muazzam derecede düşüren çok daha yavaş bir karşılaştırma kullanılmalıdır.
6. .NET, geçici arabirimleri (Go veya Rust'ta sunulanlar gibi) yüksek performanslı bir şekilde destekleyemiyor gibi görünüyor. Bu tür arabirimler , sınıf açıkça bu arabirimi uygulamasa bile List<T>bir varsayıma IListSource<U>(burada T: U) dönüştürme yapmanıza izin verirdi . Bu işlevselliği sağlamak için en az üç farklı kitaplık vardır (bağımsız olarak yazılır) (elbette performans dezavantajlarıyla birlikte - mükemmel bir çözüm mümkün olsaydı, bunu .NET'te bir kusur olarak adlandırmak adil olmazdı).
7. Diğer performans sorunları: IEnumerator yineleme başına iki arabirim çağrısı gerektirir. Düz yöntem işaretçileri (IntPtr boyutlu açık temsilciler) veya değer türü temsilciler (IntPtr * 2) mümkün değildir. Sabit boyutlu diziler (rastgele tip T) sınıfların içine gömülemez. Yok WeakReference<T>(kendi yazınızı kolayca yazabilirsiniz, ancak dahili olarak dökümleri kullanacaktır.)
8. Aynı delege türlerinin uyumsuz olarak kabul edilmesi (örtük dönüştürme yok) bazı durumlarda (örn. Predicate<T>Vs Func<T,bool>) benim için rahatsızlık yarattı . Sıklıkla , bileşenler arasında daha gevşek bir bağlantı elde etmek için arabirimler ve temsilciler için yapısal tipleme yapabilmeyi diliyorum , çünkü .NET'te bağımsız DLL'lerdeki sınıfların aynı arabirimi uygulaması yeterli değildir - aynı zamanda üçüncü birine ortak bir referansı paylaşmaları gerekir Arayüzü tanımlayan DLL.
9. DBNull.Valuenullaynı amaca eşit derecede iyi hizmet etmiş olsa bile vardır .
10. C # 'da ?? = operatörü yoktur; yazmalısın variable = variable ?? value. Gerçekten de, C # 'da gereksiz yere simetriden yoksun olan birkaç yer vardır. Örneğin if (x) y(); else z();(parantez olmadan) yazabilirsiniz , ancak yazamazsınız try y(); finally z();.
11. Bir evre yaratırken, alt evrenin ana evreden evre-yerel değerleri devralmasına neden olmak imkansızdır. BCL yalnızca bunu desteklemez, aynı zamanda tüm evreleri manuel olarak oluşturmadıkça kendiniz uygulayamazsınız; bir iş parçacığı oluşturma olayı olsa bile, .NET size belirli bir iş parçacığının "ebeveynlerini" veya "alt öğelerini" söyleyemez .
12. Farklı veri türleri için "Uzunluk" ve "Sayım" olmak üzere iki farklı uzunluk özniteliğinin olması küçük bir sıkıntıdır.
13. WPF'nin zayıf tasarımı hakkında sonsuza kadar devam edebilirim ... ve WCF (bazı senaryolar için oldukça yararlı olsa da) da siğillerle doludur. Genel olarak, BCL'nin yeni alt kitaplıklarının çoğunun şişkinliği, farkında olmaması ve sınırlı dokümantasyonu, beni bunları kullanmakta isteksiz kılıyor. Yeni şeylerin çoğu çok daha basit, daha küçük, kullanımı ve anlaşılması daha kolay, daha gevşek bir şekilde birleştirilmiş, daha iyi belgelenmiş, daha fazla kullanım senaryosuna uygulanabilir, daha hızlı ve / veya daha güçlü yazılmış olabilirdi.
14. Genellikle özellik alıcıları ve ayarlayıcılar arasındaki gereksiz bağlantı tarafından ısırılırım: Türetilmiş bir sınıfta veya türetilmiş arabirimde, temel sınıf veya temel arabirim yalnızca bir alıcıya sahipken bir ayarlayıcı ekleyemezsiniz; bir alıcıyı geçersiz kılarsanız, bir ayarlayıcı tanımlamanıza izin verilmez; ve ayarlayıcıyı sanal, alıcıyı sanal olmayan olarak tanımlayamazsınız.

1.x'te beni işaretleyen bir şey System.Xml.XmlValidatingReader, ValidationEventHandler's' ler ValidationEventArgs, ve XmlSchemaExceptiongibi tüm yararlı bilgileri içeren temelini (dahili olarak işaretlenmiş) açığa çıkarmamasıydı . Bunun yerine, bunu Message string özelliğinden ayırmanız veya ortaya çıkarmak için yansıma kullanmanız beklenir. Son kullanıcıya daha temiz bir hata vermek istediğinizde o kadar iyi değil.linenumberposition

Bir numaralamanın değerlerini başka bir numaralandırmada kullanamamanız hoşunuza gitmiyor, örneğin:

    enum Colors { white, blue, green, red, black, yellow }

    enum SpecialColors { Colors.blue, Colors.red, Colors.Yellow } 

Örtük olarak yazılan değişkenler kötü bir şekilde IMO olarak uygulanmıştır. Bunları gerçekten yalnızca Linq ifadeleriyle çalışırken kullanmanız gerektiğini biliyorum, ancak bunları yerel kapsamın dışında ilan edememeniz can sıkıcı.

MSDN'den:

• var yalnızca yerel bir değişken bildirildiğinde ve aynı ifadede başlatıldığında kullanılabilir; değişken null olarak veya bir yöntem grubuna veya anonim bir işleve başlatılamaz.
• var, sınıf kapsamındaki alanlarda kullanılamaz.
• Var kullanılarak bildirilen değişkenler, başlatma ifadesinde kullanılamaz. Başka bir deyişle, bu ifade yasaldır: int i = (i = 20); ancak bu ifade bir derleme zamanı hatası üretir: var i = (i = 20);
• Birden çok örtük olarak yazılmış değişken, aynı ifadede başlatılamaz.
• Var adlı bir tür kapsam dahilindeyse, var anahtar sözcüğü bu tür adına çözümlenecek ve örtük olarak yazılan yerel değişken bildiriminin bir parçası olarak değerlendirilmeyecektir.

Bunun zayıf bir uygulama olduğunu düşünmemin nedeni, ona var dedikleri, ancak bir varyant olmaktan çok uzak. Sınıf adını tam olarak yazmak zorunda kalmamak için gerçekten sadece kısa sözdizimidir (Linq ile kullanılması dışında)