Ist es eine schlechte Idee, das neue dynamische Schlüsselwort als Ersatz-Switch-Anweisung zu verwenden?

Es kommt wirklich darauf an, was Sie für eine "gute Idee" halten.

Das funktioniert, und es funktioniert auf ziemlich elegante Weise. Es hat einige Vorteile und einige Nachteile für andere Ansätze.

Auf der Vorteilsseite:

1. Es ist prägnant und einfach zu erweitern
2. Der Code ist ziemlich einfach

Für die Nachteile:

1. Die Fehlerprüfung ist möglicherweise schwieriger als eine klassische Besucherimplementierung, da alle Fehlerprüfungen zur Laufzeit durchgeführt werden müssen. Zum Beispiel, wenn Sie visitorTest.DynamicVisit(4.2); übergeben, erhalten Sie eine Ausnahme zur Laufzeit, aber keine Kompilierungszeit Beschwerden.
2. Der Code ist möglicherweise weniger offensichtlich und verursacht höhere Wartungskosten.

Ich persönlich halte dies für einen vernünftigen Ansatz. Das Besuchermuster hat in einer klassischen Implementierung einen ziemlich hohen Wartungsaufwand und ist oft schwierig sauber zu testen. Dies erhöht möglicherweise die Kosten geringfügig, macht aber die Implementierung viel einfacher.

Bei einer guten Fehlerprüfung habe ich kein Problem mit dynamic als Ansatz. Persönlich würde ich wahrscheinlich einen solchen Ansatz verwenden, da die Alternativen, die auf vernünftige Weise funktionieren, sonst ziemlich unangenehm werden.

Allerdings gibt es ein paar Änderungen, die ich hier machen würde. Erstens, wie ich bereits erwähnt habe, müssen Sie wirklich eine Fehlerüberprüfung einbeziehen.

Zweitens würde ich tatsächlich DynamicVisit direkt dynamic nehmen lassen, was es (etwas) offensichtlicher machen könnte, was passiert:

Das Besuchermuster existiert hauptsächlich, um die Tatsache zu umgehen, dass einige Sprachen double dispatch und mehrfachen Versand .

  

Multiple Dispatch oder Multimethods ist das Merkmal einiger objektorientierter Programmiersprachen, in denen eine Funktion oder Methode dynamisch basierend auf dem Laufzeittyp (dynamisch) von mehr als einem ihrer Argumente ausgelöst werden kann. Dies ist eine Erweiterung des einzelnen Dispatch-Polymorphismus, bei dem ein Methodenaufruf basierend auf dem tatsächlichen abgeleiteten Objekttyp dynamisch ausgelöst wird. Multiple Dispatch verallgemeinert das dynamische Dispatching, um mit einer Kombination aus zwei oder mehr Objekten zu arbeiten.

Bis Version 4 war C # eine dieser Sprachen. Mit der Einführung des Schlüsselworts dynamic ermöglicht C # jedoch Entwicklern, sich für diesen Dispatchmechanismus zu entscheiden, wie Sie es bereits gezeigt haben. Ich sehe nichts falsch daran, es auf diese Weise zu benutzen.

Sie haben die Typensicherheit überhaupt nicht geändert, weil sogar ein switch (oder wahrscheinlicher Versandwörterbuch, da C # den Typ nicht einschalten kann) einen default case haben müsste, der es auslöst kann eine aufzurufende Funktion nicht zuordnen, und dies wird genau dasselbe tun, wenn sie keine geeignete Funktion zum Binden finden kann.