Reflection Private Felder

Hallo Community,

ich habe schon im Forum gesucht, aber leider nichts zu diesem Thema gefunden. Und zwar... warum ist es möglich per Reflection auf Private Felder zuzugreifen und diese sogar zu verändern?
Private Felder sind doch dazu da, damit außenstehende dass genau nicht machen können!
zB erstelle ich Propertys damit nicht direkt auf ein Feld zugegriffen wird, um vielleicht eine Prüfung o.ä. durchzuführen. Aber per Reflection kann man jetzt direkt auf das Feld zugreifen und den Wert ändern...

Kann mir irgendjemand von euch erklären was da der Sinn dahinter ist?

Gruß
Bakunin

Hallo Bakunin,

es gibt diverse Fälle, in denen der Zugriff auf private Felder anderer Klassen notwendig und sinnvoll ist, z.B. in BinaryFormatter um beliebige Objekte serialisieren zu können. Ich habe der Zugriff auf private Felder anderer Klassen auch schon in eigenen Service-Klassen benutzt. In Business-Klassen hat sowas aber nichts zu suchen.

herbivore

Original von herbivore
Hallo Bakunin,

es gibt diverse Fälle, in denen der Zugriff auf private Felder anderer Klassen notwendig und sinnvoll ist, z.B. in BinaryFormatter um beliebige Objekte serialisieren zu können. Ich habe der Zugriff auf private Felder anderer Klassen auch schon in eigenen Service-Klassen benutzt. In Business-Klassen hat sowas aber nichts zu suchen.

herbivore

Was mich ein wenig stört ist, dass meiner Meinung nach sowas einfach nicht passieren darf. Somit kannst du dich als Entwickler ja nichtmal mehr darauf verlassen (oder gibt es eine Möglichkeit?), dass jemand deine Privaten Felder manipuliert ... ich denke da erschließt sich dann eine große Fehlerquelle.

Ist das eigentlich nur bei .NET so oder auch in anderen Sprachen?

PS: Erklär doch bitte genauer wieso du einen Zugrif auf die Privaten Felder gemacht hast, dann könnte ich mir vielleicht besser vorstellen warum sowas möglich sein soll.

Danke,
Bakunin

Hallo Bakunin,

Somit kannst du dich als Entwickler ja nichtmal mehr darauf verlassen (oder gibt es eine Möglichkeit?), dass jemand deine Privaten Felder manipuliert

wenn du eine Klasse schreibst, die nicht funktioniert, weil der Benutzer der Klasse unsinnig auf die privaten Felder zugreift, ist das nicht dein Problem.

Ist das eigentlich nur bei .NET so oder auch in anderen Sprachen?

In C++ ist es noch viel leichter auf die privaten Felder zuzugreifen. Da C++ mit Headerfiles arbeitet, brauchst du dort nur private in public zu ändern und schon hast du vollen Zugriff.

PS: Erklär doch bitte genauer wieso du einen Zugrif auf die Privaten Felder gemacht hast, dann könnte ich mir vielleicht besser vorstellen warum sowas möglich sein soll.

In einen Fall habe ich quasi einen Serialisierer für ini-Dateien geschrieben (eine Frage, die ich in dem Zusammenhang hatte, steht in Zugriff per Reflection auf vererbte private Felder ).

In einem anderen Fall ging es um das Sichern des Zustandes von Objekten, um das unangemessene Klonen zu vermeiden: Kopie ohne IClonable .

In einem weiteren Fall habe ich einfach nur eine Methode aufgerufen, von der ich meine, dass sie public sein sollte/müsste: ContextMenu bei Linksklick auf NotifyIcon anzeigen .

Grundsätzlich halte ich aber den Zugriff auf private Felder nur für Service-/Infrastruktur-Klassen für sinnvoll. Dort ist es aber auch oft wirklich hilfreich und notwendig.

herbivore

Original von herbivore
Hallo Bakunin,

Somit kannst du dich als Entwickler ja nichtmal mehr darauf verlassen (oder gibt es eine Möglichkeit?), dass jemand deine Privaten Felder manipuliert
wenn du eine Klasse schreibst, die nicht funktioniert, weil der Benutzer der Klasse unsinnig auf die privaten Felder zugreift, ist das nicht dein Problem.

Stimmt auch wieder 🙂

Original von herbivore

Ist das eigentlich nur bei .NET so oder auch in anderen Sprachen?
In C++ ist es noch viel leichter auf die privaten Felder zuzugreifen. Da C++ mit Headerfiles arbeitet, brauchst du dort nur private in public zu ändern und schon hast du vollen Zugriff.

Das ist meiner Meinung nach was anderes, denn hier veränderst du den Code!

Die ersten zwei Links hatte ich eh schon gefunden. Ich werde mir das noch genauer anschaun.

Vielleicht werde ich selbst mal feststellen, dass es sinnvoll ist, aber z.Z kann ich es mir nicht vorstellen. Klar, wenn ich wie du mal denken würde, dass zB eine Methode public sein sollte, dann ist sowas fein... aber ehrlich gesagt ändere ich dann lieber den Code... wobei der Code dann natürlich opensource sein muss 🙂. (Was sowieso so sein sollte 😉).

Danke für die Antworten!
lg
Bakunin

//edit
jetzt ist mir noch was eingefallen 😉

und zwar.. Wenn du sagst, der User ist dann selbst Schuld ist meiner Meinung schon auch richtig. Aber wenn der User nichtmal die Möglichkeit dazu hätte, könnte er auch nichts anrichten 🙂.

Wenn ein Entwickler in VB6 ein Boolean Datentyp in einen String umwandelt (vielleicht sogar durch einen Fehler) und VB6 lässt das zu, dann ist natürlich auch der Entwickler Schuld, aber es wäre aus meiner Sicht auch besser wenn VB6 sowas gar nicht zulassen würde!

Oder hast du (ihr) da andere Ansichten?

lg
Bakunin

Hallo Bakunin,

Das ist meiner Meinung nach was anderes, denn hier veränderst du den Code!

Es geht in C++ dank der Pointer-Arithmetik natürlich auch ohne Code-Änderung. Mir schien nur die Code-Änderung der bequemste und am wenigsten fehleranfällige Weg. 🙂

Vielleicht werde ich selbst mal feststellen, dass es sinnvoll ist, aber z.Z kann ich es mir nicht vorstellen.

Schade, ich hatte ja nun wirklich handfeste Beispiel genannte. Es wundert mich auch wirklich, dass die dich nicht überzeugen. Wie gesagt, sinnvoll ist es im Wesentlichen nur für Service-/Infrastruktur-Klassen, aber da ist es auch sinnvoll.

So wie man in C++ die Pointer-Arithmetik zum unsinnigen Zugriff missbrauchen kann, kann man in C# die Reflection dazu missbrauchen. Aber jede Technik lässt sich missbrauchen. Wenn man den Wert einer Technik nur nach den Missbrauchsmöglichkeiten bewertet, ist man m.E. auf dem Holzweg. Und der Nutzen von Reflection ist auf jeden Fall gegeben.

herbivore

mal eine ganz doofe frage ist ein Debuger nicht eine praktische und sinnvolle anwenden der ja eigendlich auch nur über Reflection auf die Privaten Felder zugreift.

Ich glaub ein Debugger funktioniert ein bisschen anders.

Original von herbivore
Hallo Bakunin,

Schade, ich hatte ja nun wirklich handfeste Beispiel genannte. Es wundert mich auch wirklich, dass die dich nicht überzeugen. Wie gesagt, sinnvoll ist es im Wesentlichen nur für Service-/Infrastruktur-Klassen, aber da ist es auch sinnvoll.

So wie man in C++ die Pointer-Arithmetik zum unsinnigen Zugriff missbrauchen kann, kann man in C# die Reflection dazu missbrauchen. Aber jede Technik lässt sich missbrauchen. Wenn man den Wert einer Technik nur nach den Missbrauchsmöglichkeiten bewertet, ist man m.E. auf dem Holzweg. Und der Nutzen von Reflection ist auf jeden Fall gegeben.

herbivore

Hallo herbivore,

ich konnte die Beispiele gestern nicht mehr durchlesen. Habe ich aber jetzt gerade gemacht.

zum 1 Beispiel: Hast du das eigentlich noch irgendwie gelöst? Würde mich interessieren.
zum 2 Beispiel: Sehr interessante Geschichte! Und das Beispiel hat mich eigentlich auch überzeugt, dass es sinnvoll sein kann 🙂.

Klar kann man jede Technik missbrauchen, aber wie gesagt: je weniger sich missbrauchen lässt, desto weniger wird missbraucht (also davon bin ich überzeugt ^^).

Aber das 2 Beispiel hat mich wie gesagt überzeugt und für solche Fälle ist es auf jeden Fall ok! Solange man Reflection bewusst einsetzt ist es wirklich toll!

Danke nochmals für die Antworten herbivore.

Hallo Bakunin,

zum 1 Beispiel: Hast du das eigentlich noch irgendwie gelöst? Würde mich interessieren.

ich habe es dann so gemacht, wie Pulpapex vorgeschlagen hat.

herbivore

Original von Bakunin

Somit kannst du dich als Entwickler ja nichtmal mehr darauf verlassen (oder gibt es eine Möglichkeit?), dass jemand deine Privaten Felder manipuliert ... ich denke da erschließt sich dann eine große Fehlerquelle.

Danke,
Bakunin

Ich glaube, da liegt ein Mißverständnis vor. Zugriffskontrolle, wir wir sie in Form von public/private/usw. kennen, ist keine Firewall oder Schutzmaßnahme gegen gewollten "Mißbrauch". Damit sollen Fehler (!) vermieden werden, und zwar meist die eigenen oder die der "Benutzer" deines Codes.

Nur passiert einem die Manipulation einer Variablen via Reflection mal nicht "aus Versehen". Das sind ein paar Zeilen Code.

Insofern gibt es hier keine "Fehlerquelle", höchsten eine "Mißbrauchsquelle", aber die ist bis jetzt in Programmiersprachen kein Thema (außer managed Code an sich).

Hallo svenson,

Original von svenson
Nur passiert einem die Manipulation einer Variablen via Reflection mal nicht "aus Versehen". Das sind ein paar Zeilen Code.

Ich habe eigentlich gemeint, dass der "Benutzer" meines Codes, mal auf die schnelle eine private Methode aufruft, oder eine private Variable setzt, weil er zB zu faul ist um sich die Doku o.ä. anzusehen um zu verstehen, warum man keinen direkten Zugriff auf diese Methoden und Variablen hat.

Aber du hast schon recht, Mißbrauchquelle ist der richtige Begriff.

lg
Bakunin