C # (.NET) Designfehler [geschlossen]

Was sind einige der größten Designfehler in C # oder .NET Framework im Allgemeinen?

Beispiel: Es gibt keinen nicht nullbaren Zeichenfolgentyp und Sie müssen beim Abrufen von Werten aus einem IDataReader nach DBNull suchen.

Ich stimme diesem Beitrag nachdrücklich zu (für diejenigen, die das Fehlen von ToString vermasseln, gibt es ein Debugger-Attribut, um ein benutzerdefiniertes Format für Ihre Klasse bereitzustellen).

Zusätzlich zu der obigen Liste möchte ich die folgenden angemessenen Anforderungen hinzufügen:

1. nicht nullbare Referenztypen als Ergänzung zu nullbaren Werttypen,
2. Erlaube das Überschreiben des leeren Konstruktors einer Struktur.
3. generische Typeinschränkungen zulassen, um versiegelte Klassen anzugeben,
4. Ich stimme hier einem anderen Poster zu, das willkürliche Konstruktorsignaturen angefordert hat, wenn es als Einschränkungen verwendet wurde, d. H. wo T : new(string)oder woT : new(string, int)
5. Ich stimme hier auch einem anderen Poster über das Beheben von Ereignissen zu, sowohl für leere Ereignislisten als auch in der gleichzeitigen Einstellung (obwohl letzteres schwierig ist).
6. Operatoren sollten als Erweiterungsmethoden definiert werden und nicht als statische Methoden der Klasse (oder zumindest nicht nur als statische Methoden).
7. statische Eigenschaften und Methoden für Schnittstellen zulassen (Java hat dies, C # jedoch nicht),
8. Ereignisinitialisierung in Objektinitialisierern zulassen (derzeit sind nur Felder und Eigenschaften zulässig),
9. Warum kann die Syntax "Objektinitialisierer" nur beim Erstellen eines Objekts verwendet werden? Warum nicht jederzeit verfügbar machen, dh.var e = new Foo(); e { Bar = baz };
10. quadratisches Aufzählungsverhalten korrigieren ,
11. Alle Sammlungen sollten unveränderliche Snapshots für die Iteration enthalten (dh das Mutieren der Sammlung sollte den Iterator nicht ungültig machen).
12. Tupel lassen sich leicht hinzufügen, ein effizienter geschlossener algebraischer Typ wie " Either<T>" jedoch nicht. Daher würde ich gerne einen geschlossenen algebraischen Typ deklarieren und einen umfassenden Mustervergleich erzwingen (im Grunde erstklassige Unterstützung für das Besuchermuster, aber weitaus effizienter); Nehmen Sie einfach Aufzählungen, erweitern Sie sie mit umfassender Unterstützung für den Mustervergleich und lassen Sie keine ungültigen Fälle zu.
13. Ich würde die Unterstützung für den Mustervergleich im Allgemeinen lieben, aber zumindest für das Testen von Objekttypen. Ich mag auch die Switch-Syntax, die in einem anderen Beitrag hier vorgeschlagen wurde.
14. Ich stimme einem anderen Beitrag zu, dass die System.IOKlassen Streametwas schlecht gestaltet sind; Jede Schnittstelle, für deren Ausführung einige Implementierungen erforderlich sind, NotSupportedExceptionist ein schlechtes Design.
15. IListsollte viel einfacher sein als es ist; in der Tat kann dies für viele der konkreten Sammlungsschnittstellen zutreffen, wie z ICollection.
16. Zu viele Methoden lösen Ausnahmen aus, wie z. B. IDictionary.
17. Ich würde eine Form von geprüften Ausnahmen bevorzugen, die besser ist als die in Java verfügbare (siehe die Forschung zu Typ- und Effektsystemen, wie dies getan werden kann).
18. Behebung verschiedener lästiger Eckfälle bei der generischen Methodenüberlastungsauflösung; Versuchen Sie beispielsweise, zwei überladene Erweiterungsmethoden bereitzustellen, eine für Referenztypen und eine für nullfähige Strukturtypen, und sehen Sie, wie Ihre Typinferenz dies mag.
19. bieten eine Möglichkeit, Feld- und Mitgliedsnamen für Schnittstellen wie diese INotifyPropertyChanged, die den Feldnamen als Zeichenfolge verwenden , sicher zu reflektieren ; Sie können dies tun, indem Sie eine Erweiterungsmethode verwenden, die ein Lambda mit a MemberExpression, dh, verwendet. () => Foo, aber das ist nicht sehr effizient,
    • Update: C # 6.0 hat den nameof()Operator für einzelne Mitgliedsnamen hinzugefügt , funktioniert jedoch nicht in Generika ( nameof(T) == "T"anstelle des tatsächlichen Namens des Typarguments: Sie müssen dies noch tun typeof(T).Name). Außerdem können Sie keine "Pfad" -String abrufen , z. B. nameof(this.ComplexProperty.Value) == "Value"Einschränkung seiner möglichen Anwendungen.
20. Zulassen von Operatoren in Schnittstellen und Implementieren aller Kernnummerntypen IArithmetic; andere nützliche gemeinsam genutzte Bedienerschnittstellen sind ebenfalls möglich,
21. Machen Sie es schwieriger, Objektfelder / -eigenschaften zu mutieren, oder erlauben Sie zumindest das Annotieren unveränderlicher Felder und lassen Sie die Typprüfung dies erzwingen (behandeln Sie es einfach als Nur-Getter-Eigenschaft, um Himmels willen, es ist nicht schwer!). Vereinheitlichen Sie Felder und Eigenschaften auf vernünftigere Weise, da es keinen Sinn macht, beides zu haben. Die automatischen Eigenschaften von C # 3.0 sind ein erster Schritt in diese Richtung, aber sie gehen nicht weit genug.
    • Update: Während C # das readonlySchlüsselwort hatte und C # 6.0 schreibgeschützte automatische Eigenschaften hinzufügte, ist es nicht so streng wie die echte Sprachunterstützung für unveränderliche Typen und Werte.
22. das Deklarieren von Konstruktoren vereinfachen; Ich mag den Ansatz von F #, aber der andere Beitrag hier, der einfach "neu" anstelle des Klassennamens erfordert, ist zumindest besser.

Das reicht wohl erstmal. Dies sind alles Irritationen, auf die ich in der letzten Woche gestoßen bin. Ich könnte wahrscheinlich stundenlang weitermachen, wenn ich mich wirklich darauf konzentrieren würde. C # 4.0 fügt bereits benannte, optionale und Standardargumente hinzu, die ich ausdrücklich befürworte.

Nun zu einer unvernünftigen Bitte:

1. Es wäre wirklich sehr schön, wenn C # / CLR den Typkonstruktor-Polymorphismus unterstützen könnte, d. h. Generika über Generika,

Bitte schön? :-)

• Die Reset()Methode IEnumerator<T>war ein Fehler (für Iteratorblöcke verlangt die Sprachspezifikation sogar , dass dies eine Ausnahme auslöst)
• Die Reflexionsmethoden, die Arrays zurückgeben, waren nach Erics Ansicht ein Fehler
• Array-Kovarianz war und ist eine Kuriosität
  • Update: C # 4.0 mit .NET 4.0 hat generischen Schnittstellen (wie IEnumerable<out T>und Func<in T, out TResult>, aber keine konkreten Typen (wie List<T>)) Unterstützung für Kovarianten / Kontravarianzen hinzugefügt .
• ApplicationException eher in Ungnade gefallen - war das ein Fehler?
• synchronisierte Sammlungen - eine nette Idee, aber in der Realität nicht unbedingt nützlich: Normalerweise müssen Sie ( dann ) mehrere Operationen synchronisieren , sodass eine Sammlung, die unterschiedliche Operationen synchronisiert, nicht allzu nützlich ist ContainsAdd
  • Update: Die System.Collections.ConcurrentTypen , mit TryAdd, GetOrAdd, TryRemove, etc wurden in .NET Framework 4.0 hinzugefügt - obwohl Methoden , die eine Fabrik Delegierten nehmen nicht die Fabrik Garantie wird nur einmal pro Taste aufgerufen werden.
• Das using/ lockpattern hätte besser genutzt werden können - vielleicht könnten sie eine wiederverwendbare (erweiterbare?) Syntax verwenden; Sie können dies simulieren, indem Sie zurückkehren IDisposableund verwenden using, aber es hätte klarer sein können
• Iteratorblöcke: Keine einfache Möglichkeit, Argumente vorab zu überprüfen (anstatt träge). Natürlich können Sie zwei verkettete Methoden schreiben, aber das ist hässlich
• einfachere Unveränderlichkeit wäre schön; C # 4.0 hilft ein bisschen , aber nicht genug
• Keine Unterstützung für "Dieser Ref-Typ-Parameter kann nicht null sein" - obwohl Verträge (in 4.0) dabei etwas helfen. Aber Syntax wie Foo(SqlConnection! connection)(die einen Null-Check / einfügt throw) wäre schön (im Gegensatz zu int?etc)
  • Update: Dies ist in C # 8.0 behoben .
• mangelnde Unterstützung von Operatoren und Nicht-Standardkonstruktoren mit Generika; C # 4.0 löst dieses Problem etwas mit dynamic, oder Sie können es ermöglichen , wie dies
• Die Iteratorvariable wird außerhalb der Zeit in der foreachErweiterung deklariert , was bedeutet, dass anon-Methods / Lambdas die einzelne Variable erfassen und nicht eine pro Iteration (schmerzhaft beim Threading / async / etc).
  • Update: Dies wurde in C # 5.0 behoben .

TextWriter ist eine Basisklasse von StreamWriter. wtf?

Das verwirrt mich immer bis zum Äußersten.

Ein kleiner C # pet peev - Konstruktor verwendet die C ++ / Java-Syntax, bei der der Konstruktor den gleichen Namen wie die Klasse hat.

New()oder ctor()wäre viel schöner gewesen.

Tools wie Coderush machen dies zwar weniger zu einem Problem beim Umbenennen von Klassen, aber New () bietet aus Gründen der Lesbarkeit eine große Klarheit.

Ich verstehe nicht, dass du es nicht kannst

wo T: neu (U)

Sie deklarieren also, dass der generische Typ T einen nicht standardmäßigen Konstruktor hat.

bearbeiten:

Ich möchte das machen:

public class A 
{
    public A(string text) 
    {

    }
}


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

}

Ich bin wirklich überrascht, dass ich als erster diesen erwähne:

ADO.NET-typisierte Datensätze machen nullfähige Spalten nicht als Eigenschaften nullbarer Typen verfügbar. Sie sollten in der Lage sein, dies zu schreiben:

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

Stattdessen muss man das schreiben, was einfach nur dumm ist:

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

Dies war in .NET 2.0 ärgerlich, und es ist jetzt noch ärgerlicher, dass Sie in Ihren netten, ordentlichen LINQ-Abfragen Jiggery-Pokery wie oben verwenden müssen.

Es ist auch ärgerlich, dass die generierte Add<TableName>RowMethode für den Begriff der nullbaren Typen ähnlich unempfindlich ist. Dies gilt umso mehr, als die generierten TableAdapterMethoden dies nicht tun .

In .NET gibt es nicht viel, was mir das Gefühl gibt, dass das Entwicklerteam sagte: "Okay, Jungs, wir sind nah genug dran - versenden Sie es!" Aber das tut es sicher.

1. Ich bin kein großer Fan der Klassen Stream, StringWriter, StringReader, TextReader, TextWriter ... es ist einfach nicht intuitiv, was was ist.
2. IEnumerable.Reset löst eine Ausnahme für Iteratoren aus. Ich habe einige Komponenten von Drittanbietern, die immer das Zurücksetzen aufrufen, wenn sie datengebunden sind. Daher muss ich sie zuerst in eine Liste umwandeln, um diese zu verwenden.
3. Xml Serializer sollte IDictionary-Elemente serialisiert haben
4. Ich habe die HttpWebRequest & FTP API total vergessen, was für ein Schmerz in meinem .... (danke für den Kommentar Nicholas, der mich daran erinnert :-)

Bearbeiten
5. Ein weiteres Ärgernis von mir ist, wie System.Reflection.BindingFlags je nach verwendeter Methode unterschiedliche Verwendungszwecke hat. Was bedeutet beispielsweise in FindFields CreateInstance oder SetField? Dies ist ein Fall, in dem sie die Bedeutung hinter dieser Aufzählung überladen haben, was verwirrend ist.

Ich weiß nicht, dass ich sagen würde, dass es sich um einen Designfehler handelt, aber es wäre wirklich schön, wenn Sie einen Lambda-Ausdruck auf die gleiche Weise wie in VB ableiten könnten:

VB:

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

C #

Es wäre schön, wenn dies möglich wäre:

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

Anstatt dies tun zu müssen:

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

Mir ist klar, dass es nicht mehr lange dauert, aber im Code Golf zählt jeder Charakter verdammt! Berücksichtigen sie das nicht, wenn sie diese Programmiersprachen entwerfen? :) :)

1. Die System.Object- Klasse:

   • Equals und GetHashCode - nicht alle Klassen sind vergleichbar oder hashbar, sollten auf eine Schnittstelle verschoben werden. IEquatable oder IComparable (oder ähnliches) fällt mir ein.

   • ToString - Nicht alle Klassen können in eine Zeichenfolge konvertiert werden. Sie sollten in eine Schnittstelle verschoben werden. IFormattable (oder ähnliches) fällt mir ein.

2. Die ICollection.SyncRoot- Eigenschaft:

   • Fördert schlechtes Design, ein externes Schloss ist fast immer nützlicher.

3. Generika sollten von Anfang an dabei gewesen sein:

   • Der System.Collections- Namespace enthält viele mehr oder weniger veraltete Klassen und Schnittstellen.

Eines der Dinge, die mich irritieren, ist das Predicate<T> != Func<T, bool>Paradoxon. Sie sind beide Delegierte des Typs T -> boolund dennoch nicht zuweisungskompatibel.

Einige Leute (ISVs) wünschen sich, dass Sie es zur Erstellungszeit zu Maschinencode kompilieren und verknüpfen können, um eine native ausführbare Datei zu erstellen, die die dotNet-Laufzeit nicht benötigt.

Wir wissen so viel über die richtigen OO-Techniken. Entkopplung, vertragliche Programmierung, Vermeidung unzulässiger Vererbung, angemessene Verwendung von Ausnahmen, offenes / geschlossenes Prinzip, Liskov-Substituierbarkeit usw. In den .Net-Frameworks werden noch keine Best Practices verwendet.

Für mich liegt der größte Fehler im Design von .Net nicht auf den Schultern von Riesen. Förderung weniger als idealer Programmierparadigmen für die Masse der Programmierer, die ihre Frameworks verwenden .

Wenn MS dies beachtet hätte, hätte die Welt der Softwareentwicklung in diesem Jahrzehnt große Fortschritte in Bezug auf Qualität, Stabilität und Skalierbarkeit machen können, aber leider scheint sie rückläufig zu sein.

Ich mag die C # switch-Anweisung nicht.

Ich hätte gerne so etwas

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

Also keine Pausen mehr (leicht zu vergessen) und die Möglichkeit, verschiedene Werte durch Kommas zu trennen.

Ereignisse in C #, bei denen Sie explizit nach Listenern suchen müssen. War das nicht der Punkt bei Ereignissen, an jemanden zu senden, der gerade dort war? Auch wenn es keine gibt?

Das schreckliche (und für die meisten Menschen völlig unsichtbare) O (N ^ 2) -Verhalten verschachtelter / rekursiver Iteratoren .

Ich bin ziemlich enttäuscht, dass sie darüber Bescheid wissen und wissen, wie man es behebt, aber es wird nicht als ausreichend priorisiert angesehen, um die Aufnahme zu verdienen.

Ich arbeite die ganze Zeit mit baumartigen Strukturen und muss den Code ansonsten kluger Leute korrigieren, wenn sie auf diese Weise versehentlich sehr teure Operationen einführen.

Das Schöne an "Yield Foreach" ist, dass die einfachere, einfachere Syntax korrekten, performanten Code fördert. Dies ist die "Grube des Erfolgs" , nach der sie meiner Meinung nach streben sollten, bevor sie neue Funktionen für den langfristigen Erfolg der Plattform hinzufügen.

Einige Klassen implementieren Schnittstellen, aber sie implementieren nicht viele der Methoden dieser Schnittstelle, z. B. Array implementiert IList, aber 4 von 9 Methoden lösen NotSupportedException http://msdn.microsoft.com/en-us/library/system.array_members aus .aspx

Statische Elemente und verschachtelte Typen in Schnittstellen.

Dies ist besonders nützlich, wenn ein Schnittstellenmitglied einen Parameter eines Typs hat, der für die Schnittstelle spezifisch ist ( zenum . B. einen ). Es wäre schön, den Aufzählungstyp im Schnittstellentyp zu verschachteln.

Die schrecklich gefährliche Standardnatur von Ereignissen. Die Tatsache, dass Sie ein Ereignis aufrufen können und sich aufgrund des Entfernens von Abonnenten in einem inkonsistenten Zustand befinden, ist einfach schrecklich. Weitere Informationen zu diesem Thema finden Sie in den hervorragenden Artikeln von Jon Skeet und Eric Lippert .

• null überall.

• const nirgends.

• APIs sind inkonsistent, z. B. das Mutieren einer Array-Rückgabe void, das Anhängen an eine StringBufferRückgabe jedoch dieselbe veränderbare StringBuffer.

• Sammlungsschnittstellen sind nicht mit unveränderlichen Datenstrukturen kompatibel, z. B. Addin System.Collections.Generic.IList<_>kann kein Ergebnis zurückgeben.

• Keine strukturelle Eingabe, also schreiben Sie System.Windows.Media.Effects.SamplingMode.Bilinearstatt nur Bilinear.

• Veränderbare IEnumeratorSchnittstelle, die von Klassen implementiert wird, wenn sie unveränderlich sein soll struct.

• Gleichheit und Vergleich ist ein einziges Chaos: Sie haben System.IComparableund Equalsaber dann haben Sie auch bekommen System.IComparable<_>, System.IEquatable, System.Collections.IComparer, System.Collections.IStructuralComparable, System.Collections.IStructuralEquatable, System.Collections.Generic.IComparerund System.Collections.Generic.IEqualityComparer.

• Tupel sollten Strukturen sein, aber Strukturen verhindern unnötig die Eliminierung von Tail Calls, sodass einer der häufigsten und grundlegendsten Datentypen unnötig zugewiesen wird und skalierbare Parallelität zerstört wird.

0 Mondschein als Aufzählung

Besonderheiten der Aufzählung: http://blogs.msdn.com/abhinaba/archive/2007/01/09/more-peculiarites-of-enum.aspx

Wie dieses gute Beispiel zeigt: http://plus.kaist.ac.kr/~shoh/postgresql/Npgsql/apidocs/Npgsql.NpgsqlParameterCollection.Add_overload_3.html

Mein Vorschlag, nutzen Sie das "@" - Zeichen:

anstatt:

if ((myVar & MyEnumName.ColorRed)! = 0)

benutze das:

if ((myVar & MyEnumName.ColorRed)! = @ 0)

So ergänzen Sie die lange Liste der guten Punkte, die bereits von anderen gemacht wurden:

• DateTime.Now == DateTime.Now in den meisten, aber nicht allen Fällen.

• StringWas unveränderlich ist, hat eine Reihe von Optionen für Konstruktion und Manipulation, aber StringBuilder(was veränderlich ist) nicht.

• Monitor.Enterund Monitor.Exitsollten Instanzmethoden gewesen sein. Anstatt ein bestimmtes Objekt zum Sperren neu zu erstellen, können Sie ein neues Objekt erstellen Monitorund dieses sperren.

• Destruktoren sollten niemals Destruktoren genannt worden sein. Die ECMA-Spezifikation nennt sie Finalizer, was für die C ++ - Menge viel weniger verwirrend ist, aber die Sprachspezifikation bezeichnet sie immer noch als Destruktoren.

Die Art und Weise, wie wir Eigenschaften verwenden, irritiert mich manchmal. Ich stelle sie mir gerne als Äquivalent zu den Methoden getFoo () und setFoo () von Java vor. Aber das sind sie nicht.

Wenn in den Richtlinien zur Verwendung von Eigenschaften festgelegt ist, dass Eigenschaften in beliebiger Reihenfolge festgelegt werden können, damit die Serialisierung funktioniert, sind sie für die Überprüfung der Setterzeit unbrauchbar. Wenn Sie aus einem Hintergrund kommen, in dem Sie verhindern möchten, dass sich ein Objekt jemals in einen ungültigen Zustand versetzt, sind Eigenschaften nicht Ihre Lösung. Manchmal scheitern ich nur um zu sehen , wie sie sind besser als öffentliche Mitglieder, da sind wir so begrenzt , welche Arten von Dingen , die wir sind angeblich in Eigenschaften zu tun.

Zu diesem Zweck habe ich mir immer gewünscht (das wird hier meistens laut gedacht, ich wünschte nur, ich könnte so etwas tun), dass ich die Eigenschaftssyntax irgendwie erweitern könnte. Stellen Sie sich so etwas vor:

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;
    }
}

Ich bin mir nicht sicher, ob das nützlich ist oder wie der Zugriff darauf aussehen würde. Aber ich wünschte nur, ich könnte mehr mit Eigenschaften anfangen und sie wirklich wie get- und set-Methoden behandeln.

Erweiterungsmethoden sind nett, aber sie sind eine hässliche Möglichkeit, Probleme zu lösen, die mit echten Mixins sauberer hätten gelöst werden können (siehe Ruby, um zu sehen, wovon ich spreche), zum Thema Mixins. Eine wirklich gute Möglichkeit, sie der Sprache hinzuzufügen, wäre gewesen, Generika für die Vererbung zu verwenden. Auf diese Weise können Sie vorhandene Klassen auf eine schöne objektorientierte Weise erweitern:

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

Dies kann folgendermaßen verwendet werden, um eine Zeichenfolge zu erweitern:

var newMixin = new MyMixin<string>();

Es ist weitaus leistungsfähiger als Erweiterungsmethoden, da Sie damit Methoden überschreiben können, z. B. um sie zu verpacken und AOP-ähnliche Funktionen in der Sprache zu ermöglichen.

Entschuldigung für das Geschwätz :-)

Microsoft behebt keine offensichtlichen Fehler im Framework und stellt keine Hooks bereit, damit Endbenutzer diese beheben können.

Es gibt auch keine Möglichkeit, ausführbare .NET-Dateien zur Laufzeit binär zu patchen und keine privaten Versionen von .NET Framework-Bibliotheken anzugeben, ohne die nativen Bibliotheken binär zu patchen (um den Ladeaufruf abzufangen), und ILDASM ist nicht weiterverteilbar, sodass ich nicht automatisieren kann der Patch trotzdem.

• Die Möglichkeit, eine Erweiterungsmethode für eine Nullvariable aufzurufen, ist fraglich, z

  Objekt a = null; a.MyExtMethod (); // Dies ist aufrufbar. Nehmen wir an, irgendwo wurde MyExtMethod definiert

  Es könnte praktisch sein, ist jedoch bei Nullreferenz-Ausnahmethemen nicht eindeutig.

• Ein Namensfehler. 'C' von "configuration" in System.configuration.dll sollte groß geschrieben werden.

• Ausnahmebehandlung. Ausnahmen sollten wie in Java gewaltsam abgefangen oder ausgelöst werden. Der Compiler sollte sie beim Kompilieren überprüfen. Benutzer sollten sich nicht auf Kommentare für Ausnahmeinformationen innerhalb des Zielaufrufs verlassen.

Die .Parameters.Add () -Methode für den SqlCommand in V1 des Frameworks wurde fürchterlich entworfen - eine der Überladungen würde grundsätzlich nicht funktionieren, wenn Sie einen Parameter mit dem Wert (int) von 0 übergeben würden - dies führte dazu, dass sie erstellt wurden die Methode .Parameters.AddWithValue () für die SqlCommand-Klasse.

1. Es gibt keine Teilmengen von ICollection<T>und IList<T>; Zumindest wäre eine kovariante schreibgeschützte Erfassungsschnittstelle IListSource<out T>(mit Enumerator, Indexer und Count) äußerst nützlich gewesen.
2. .NET unterstützt keine schwachen Delegaten . Die Problemumgehungen sind bestenfalls umständlich, und Problemlösungen auf der Hörerseite sind bei teilweisem Vertrauen nicht möglich (ReflectionPermission ist erforderlich).
3. Die generische Vereinheitlichung der Schnittstelle ist verboten, auch wenn sie sinnvoll ist und keine Probleme verursacht.
4. Im Gegensatz zu C ++ sind kovariante Rückgabetypen in .NET nicht zulässig
5. Es ist nicht möglich, zwei Werttypen bitweise auf Gleichheit zu vergleichen. In einer funktionalen " persistenten " Datenstruktur habe ich eine Transform(Sequence<T>, Func<T,T>)Funktion geschrieben, mit der schnell festgestellt werden konnte, ob die Funktion denselben oder einen anderen Wert zurückgibt. Wenn die Funktion die meisten / alle Argumente nicht ändert, kann die Ausgabesequenz einen Teil / den gesamten Speicher der Eingabesequenz gemeinsam nutzen. Ohne die Möglichkeit, einen Werttyp T bitweise zu vergleichen, muss ein viel langsamerer Vergleich verwendet werden, was die Leistung enorm beeinträchtigt.
6. .NET scheint nicht in der Lage zu sein, Ad-hoc-Schnittstellen (wie die in Go oder Rust angebotenen) auf performante Weise zu unterstützen. Solche Schnittstellen hätten es Ihnen ermöglicht List<T>, eine Hypothese IListSource<U>(wobei T: U) zu erstellen, obwohl die Klasse diese Schnittstelle nicht explizit implementiert. Es gibt mindestens drei verschiedene Bibliotheken (unabhängig voneinander geschrieben), um diese Funktionalität bereitzustellen (natürlich mit Leistungsnachteilen - wenn eine perfekte Problemumgehung möglich wäre, wäre es nicht fair, sie als Fehler in .NET zu bezeichnen).
7. Weitere Leistungsprobleme: IEnumerator erfordert zwei Schnittstellenaufrufe pro Iteration. Einfache Methodenzeiger (IntPtr-offene Delegaten) oder werttypisierte Delegaten (IntPtr * 2) sind nicht möglich. Arrays mit fester Größe (vom beliebigen Typ T) können nicht in Klassen eingebettet werden. Es gibt keine WeakReference<T>(Sie können leicht Ihre eigenen schreiben, aber es werden Abgüsse intern verwendet.)
8. Die Tatsache, dass identische Delegatentypen als inkompatibel angesehen werden (keine implizite Konvertierung), war für mich gelegentlich ein Ärgernis (z . B. Predicate<T>vs Func<T,bool>). Ich wünschte oft, wir könnten eine strukturelle Typisierung für Schnittstellen und Delegaten haben, um eine lockerere Kopplung zwischen Komponenten zu erreichen, da es in .NET nicht ausreicht, dass Klassen in unabhängigen DLLs dieselbe Schnittstelle implementieren - sie müssen auch einen gemeinsamen Verweis auf eine dritte haben DLL, die die Schnittstelle definiert.
9. DBNull.Valueexistiert, obwohl nullder gleiche Zweck gleich gut gedient hätte.
10. C # hat keinen ?? = Operator; du musst schreiben variable = variable ?? value. In der Tat gibt es einige Stellen in C #, an denen es unnötig an Symmetrie mangelt. Zum Beispiel können Sie schreiben if (x) y(); else z();(ohne geschweifte Klammern), aber Sie können nicht schreiben try y(); finally z();.
11. Beim Erstellen eines Threads kann der untergeordnete Thread nicht veranlassen, threadlokale Werte vom übergeordneten Thread zu erben. Die BCL unterstützt dies nicht nur nicht, sondern Sie können es auch nicht selbst implementieren, es sei denn, Sie erstellen alle Threads manuell. Selbst wenn es ein Thread-Erstellungsereignis gab, kann .NET Ihnen nicht die "Eltern" oder "Kinder" eines bestimmten Threads mitteilen .
12. Die Tatsache, dass es zwei verschiedene Längenattribute für verschiedene Datentypen gibt, "Länge" und "Anzahl", ist ein kleines Ärgernis.
13. Ich könnte für immer über das schlechte Design von WPF reden ... und WCF (obwohl es für einige Szenarien sehr nützlich ist) ist auch voller Warzen. Im Allgemeinen lässt mich die Blähung, Unintuitivität und eingeschränkte Dokumentation vieler neuerer BCL-Unterbibliotheken zögern, sie zu verwenden. Viele der neuen Inhalte hätten viel einfacher, kleiner, benutzerfreundlicher und verständlicher, lockerer gekoppelt, besser dokumentiert, für mehr Anwendungsfälle anwendbar, schneller und / oder stärker typisiert sein können.
14. Ich bin oft von der unnötigen Kopplung zwischen Eigenschaftsträgern und Setzern gebissen worden: In einer abgeleiteten Klasse oder abgeleiteten Schnittstelle können Sie nicht einfach einen Setter hinzufügen, wenn die Basisklasse oder Basisschnittstelle nur einen Getter hat; Wenn Sie einen Getter überschreiben, dürfen Sie keinen Setter definieren. und Sie können den Setter nicht als virtuell definieren, sondern den Getter als nicht virtuell.

Eine Sache , die mich in 1.x abgehakt war , als die Verwendung System.Xml.XmlValidatingReaderder ValidationEventHandler‚s ValidationEventArgsnicht der Basiswert aussetzt XmlSchemaException(markiert intern) , die alle nützlichen Informationen hat wie linenumberund position. Stattdessen wird erwartet, dass Sie dies aus der Message-String-Eigenschaft heraus analysieren oder mithilfe von Reflection ausgraben. Nicht so gut, wenn Sie dem Endbenutzer einen bereinigten Fehler zurückgeben möchten.

Es gefällt mir nicht, dass Sie die Werte einer Aufzählung nicht in einer anderen Aufzählung verwenden können, zum Beispiel:

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

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

Implizit typisierte Variablen wurden IMO schlecht implementiert. Ich weiß, dass Sie sie wirklich nur verwenden sollten, wenn Sie mit Linq-Ausdrücken arbeiten, aber es ist ärgerlich, dass Sie sie nicht außerhalb des lokalen Bereichs deklarieren können.

Von MSDN:

• var kann nur verwendet werden, wenn eine lokale Variable in derselben Anweisung deklariert und initialisiert wird. Die Variable kann nicht mit null, einer Methodengruppe oder einer anonymen Funktion initialisiert werden.
• var kann nicht für Felder im Klassenbereich verwendet werden.
• Mit var deklarierte Variablen können nicht im Initialisierungsausdruck verwendet werden. Mit anderen Worten, dieser Ausdruck ist legal: int i = (i = 20); Dieser Ausdruck erzeugt jedoch einen Fehler bei der Kompilierung: var i = (i = 20);
• Mehrere implizit typisierte Variablen können nicht in derselben Anweisung initialisiert werden.
• Wenn sich ein Typ mit dem Namen var im Gültigkeitsbereich befindet, wird das Schlüsselwort var in diesen Typnamen aufgelöst und nicht als Teil einer implizit typisierten lokalen Variablendeklaration behandelt.

Der Grund, warum ich denke, dass es eine schlechte Implementierung ist, ist, dass sie es var nennen, aber es ist weit davon entfernt, eine Variante zu sein. Es ist wirklich nur eine Kurzsyntax, wenn Sie nicht den vollständigen Klassennamen eingeben müssen (außer bei Verwendung mit Linq).