Il modificatore private viene utilizzato per limitare l'accesso al di fuori della classe, ma utilizzando la riflessione altre classi possono accedere a campi e metodi privati. Quindi mi chiedo come possiamo limitare l'accessibilità se è parte del requisito.
Lo scopo dei modificatori di accesso è informare gli sviluppatori che scrivono il codice su quale sia l'interfaccia pubblica di una classe. Non sono in alcun modo una misura di sicurezza e non nascondono o proteggono letteralmente alcuna informazione.
Per citare Herb Sutter sui diritti di accesso alla classe :
"Il problema qui è di proteggere contro Murphy contro la protezione contro Machiavelli ... cioè, proteggendo contro l'uso improprio accidentale (che il linguaggio fa molto bene) contro la protezione contro l'abuso deliberato (che è effettivamente impossibile). fine, se un programmatore vuole abbastanza male da sovvertire il sistema, troverà un modo "
No, questo è in realtà un vantaggio importante. Semplicemente perché alcuni sviluppatori non ritenevano che qualcuno avrebbe avuto bisogno di accedere a qualche parte dello stato interno non significa che nessun caso di utilizzo legittimo si presenterà mai. In questi casi, l'uso di Reflection per eseguire un intervento chirurgico su un oggetto può essere l'ultima risorsa. Ho dovuto usare questa tecnica più di una volta.
Limiti ancora di più l'accessibilità salendo di un altro livello: l'ambiente di esecuzione.
Non tutte le lingue hanno questo concetto, ma almeno con Java puoi usare un gestore della sicurezza che vieta di rendere accessibili i campi privati. È possibile installare manualmente Security Manager in fase di runtime o aggiungere una politica di sicurezza in un file jar che viene quindi sigillato per impedire la modifica.
Ulteriori informazioni su come farlo in Java: Sicurezza di Reflection
Di quale riflessione stai parlando?
In molti sistemi di riflessione, l'incapsulamento elusivo è una capacità esplicita che il tuo codice deve ottenere e che non ha per impostazione predefinita.
Se sei preoccupato per l'incapsulamento, la soluzione semplice è semplicemente non usare un sistema di riflessione che non lo preservi.
In Python, non ci sono modificatori di accesso. La convenzione deve prefigurare con un trattino di sottolineatura i metodi e le variabili a cui non è previsto l'accesso dall'esterno della classe. Tecnicamente ti impedisce di accedere a questo campo da una classe di terze parti? Affatto; ma se lo fai, sei da solo e rischi di rompere qualcosa, senza essere in grado di incolpare l'altra classe.
In C #, esistono modificatori di accesso, ma sono ancora solo una convenzione, che è imposta da un compilatore, ma è comunque una convenzione. Ciò significa che tecnicamente, si può ancora accedere e modificare variabili private, tramite Reflection o manomettendo direttamente la memoria (come game trainer fare). La conseguenza è esattamente la stessa: se le variabili della tua classe vengono modificate tramite Reflection da un'altra classe, o attraverso la manomissione della memoria da parte di un'altra applicazione, e interrompe qualcosa nella tua classe, non è colpa tua.
Si noti che questo, ovviamente, crea problemi di sicurezza quando una terza parte può accedere ai tuoi dati; qualcosa che porta a varianti crittografate di una stringa e strutture di dati simili. Tuttavia, la protezione del codice da tale utilizzo è più simile a OS e restrizioni di accesso a livello di codice e non ha nulla a che fare con Reflection di per sé.
Leggi altre domande sui tag security reflection