Ha, sorry, hat etwas gedauert, bis ich wieder einen freien Moment gefunden hab.
Stichwort Reflection. Okay, ein kritischer Punkt war ja schon angeführt worden: Performance.
Das Problem ist, daß Reflection in .NET von anfang an zum Debugging gedacht war (note, es geht nicht darum, Reflection zu debuggen, sondern es geht darum, Reflection zu verwenden, um bestehenden Code zu debuggen.) Entsprechend wurde nie Augenmerk auf die Performance gelegt: "Normaler" Code sollte ohne Reflection auskommen, also ist egal, wie performant das ist.
Wo ich grad etwas irritiert bin... sind die angeführten Einsatzbereiche, für die Reflection helfen könnte.
Steh da bestimmt grad mit beiden Beinen auf dem Schlauch, aber dennoch, zur Veranschaulichung:
Reflection verrät mir Details über die existierende Typisierung meines Codes. Was ist was, wer erbt von wo, wenn ich ein object X hab, was steht da drin - sprich ist es eigentlich ein String oder sowas, was ich in ein object reingelegt hatte?
Reflection hat dagegen, zumindest soweit ich informiert bin, mit der Übernahme von sowas wie struct object (als Input aus einer Datenbankzeile) exakt Null zu tun. Wenn ich das in einem Objekt haben will, dann schieb ich das durch einen Konstruktor (dynamisch) oder durch eine ClassFactory(statisch). Was soll mir denn zB GetType() verraten - was will ich damit, wenn ich den Typen doch vorher schon kenne? Außer natürlich ich war so unfähig, in einer Datenbankspalte nicht zu typisieren und nun alle möglichen Werte dort haben zu können.... aber dann stimmt mein Modell nicht und ich hab immer noch keinen triftigen Grund für Reflection.
Generics sind auch immer verlockend. Da muß man tatsächlich aufpassen, weil Generics einerseits und OO andererseits sich einfach beißt. Es ist einfach, T ConvertTo<T>(object input) zu definieren und dann im Funktionskörper mit GetType() und Co um sich zu werfen, damit ConvertTo immer das Richtige tut.
Aber auch dann hat man einen Fehler im Ansatz und sollte vielleicht lieber auf Polymorphie und - da Generics -- jeweils passende Constraints pro Fall ausweichen. Bei Bedarf kann man das ja hintenrum wieder zusammenführen.
Natürlich kann ich an der Stelle nur von mir reden... aber in meinen inzwischen paar Hunderttausend Codezeilen für jeden möglichen kleinen und größeren Keks hab ich, soweit ich das sehe, einmal System.Reflection referenziert und das deswegen, weil mich die Funktionalität als solche interessiert hatte.
PowerShell zum Bleistift erlaubt mir, einfach einen Funktionsnamen in die Konsole zu schreiben (ohne Signatur) und dann sämtliche Overload-Definitions auf die Konsole zu werfen. Oder Intellisense - das macht dasselbe; es gibt keine Listen, sondern es gibt Reflection und ich erfahre beim Tippen, was es überhaupt gibt. Auch das ist im weitesten Sinne Debugging - hier zur Vermeidung von Problemen bereits bei der Entwicklung -- wo man natürlich als Anwender von profitiert.
Aber wenn das alles schon bekannt ist.... fällt es mir schwer, einen echten Sinn für die Verwendung von Reflection auszumachen.
