Mängel bei der Verwendung dynamischer Typen in C #

Ich habe kürzlich mehr über die dynamischen Typen in C # gelernt. Mit einigen Beispielen habe ich verstanden, dass der Code nach dem Kompilieren nicht erneut kompiliert werden muss, sondern direkt ausgeführt werden kann.

Ich halte die Flexibilität, die das Schlüsselwort bietet, um den Datentyp tatsächlich nach Belieben ändern zu können, für einen großen Vorteil .

Frage,

Gibt es bestimmte Mängel, abgesehen von falschen dynamischen Methodenaufrufen, die Laufzeitausnahmen auslösen, die Entwickler kennen müssen, bevor sie mit der Implementierung beginnen.

Das Hauptmanko ist, dass Sie eine der Haupteigenschaften (nicht unbedingt Vorteile) von C # wegwerfen - dass es statisch typisiert ist (und größtenteils typensicher ist).

Das Problem bei der dynamischen Typisierung besteht darin, dass häufig Fehler ausgeblendet werden, die ansonsten beim Kompilieren aufgedeckt würden. Ein solcher Fehler tritt dann nur zur Laufzeit auf, was es natürlich viel schwieriger macht, ihn zu erkennen.

Es gibt nur wenige IMO-Gründe für die Verwendung der dynamischen Typisierung in C #. Der Hauptgrund ist die Zusammenarbeit mit dynamisch typisierten Sprachen (AFAIK ist der Grund, warum die dynamische Typisierung ursprünglich eingeführt wurde).

Wenn Sie vollständig dynamisch programmieren möchten, sollten Sie sich eine Sprache ansehen, die so konzipiert ist, dass sie dynamisch ist, und nicht C #, um dynamisch zu sein. Sie können beispielsweise IronPython verwenden, wenn Sie .NET-Bibliotheken verwenden möchten

Ich bin mir nicht sicher, welche Art von Mängeln Sie suchen, aber wenn Sie wissen möchten, welche Funktionen mit statischer Eingabe funktionieren, aber nicht mit dynamic, gibt es einige:

1. Erweiterungsmethoden funktionieren nicht. Dies ist wahrscheinlich der größte. Wenn Sie haben dynamic collection, können Sie keinen Code wie verwenden collection.Distinct(). Das liegt daran, dass die verfügbaren Erweiterungsmethoden von Namespaces abhängen usingund der DLR keine Möglichkeit hat, diese zu ermitteln.

   Als Abhilfe können Sie entweder die Methode aufrufen , als ob es normale statische Methode war: Enumerable.Distinct(collection). Oder Sie können den Typ der Sammlung in etwas ändern IEnumerable<dynamic>.

2. foreacherfordert IEnumerable. In normalem C # foreachist musterbasiert. Das heißt, es ist keine bestimmte Schnittstelle erforderlich, nur eine GetEnumerator()Methode, die ein geeignetes Objekt zurückgibt. Wenn Sie foreachauf verwenden dynamic, ist die Implementierung von IEnumerableerforderlich. Aber da der Grund für dieses Verhalten darin besteht, dass C # 1.0 keine Generika hatte, ist dieses "Manko" so ziemlich irrelevant.

Das Problem mit dynamischen Typen (keine als dynamisch deklarierten Variablen) in .net besteht darin, dass statischen Typen nicht viele Funktionen zur Verfügung stehen.

• Es gibt keine Reflexion (Sie können über Mitglieder iterieren, aber nicht viel anderes)
• Keine Metadaten (da geht Ihre Validierung in Dynamic Data Sites / MVC)
• Absolut keine Überprüfung zur Kompilierungszeit (Rechtschreibfehler werden nicht abgefangen)
• da dies ein mächtiges Feature ist, neigen Noobs dazu, es zu missbrauchen / missbrauchen / misszuverstehen
• Code, der mit dynamischen Typen geschrieben wurde, ist in der Regel schwer zu warten und verdammt schwer umzugestalten
• Aufgrund der Eingabe von Enten und anderer Funktionen können Gurus Code schreiben, der für andere nicht lesbar ist

Schreiben Sie also keinen Code mit dynamischen Typen, es sei denn, Sie wissen, was Sie tun.

Da dynamices sich nur um ein gekennzeichnetes objectFeld handelt, werden Werttypen angezeigt.

Dies kann Auswirkungen auf die Leistung haben, aber da ich sowieso die statische Eingabe in leistungskritischen Code verwenden würde, ist dies in der Praxis wahrscheinlich kein Problem.

Dieses Boxen stört auch veränderbare Werttypen. Wenn Sie sie mit ändern dynamic, ändern Sie nur die Boxed Copy. Da Sie jedoch in erster Linie keine veränderlichen Werttypen verwenden sollten, ist dies auch kein großes Problem.