Reflection è uno svantaggio in quanto le variabili private non possono essere limitate?

Il privatemodificatore viene utilizzato per limitare l'accesso al di fuori della classe, ma utilizzando la riflessione altre classi possono accedere a metodi e campi privati. Quindi mi chiedo come possiamo limitare l'accessibilità se fa parte dei requisiti.

Lo scopo dei modificatori di accesso è informare gli sviluppatori che scrivono 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 è quello di proteggere contro Murphy contro proteggere contro Machiavelli ... vale a dire, proteggere contro l'uso improprio accidentale (che la lingua fa molto bene) rispetto a proteggere contro l'abuso deliberato (che è effettivamente impossibile). Alla fine, se un programmatore vuole abbastanza da sovvertire il sistema, troverà un modo "

No, questo è in realtà un vantaggio importante. Il semplice fatto che alcuni sviluppatori non abbiano ritenuto che qualcuno avrebbe avuto bisogno di accedere a una parte dello stato interno non significa che nessun caso d'uso legittimo verrà mai presentato. In questi casi, l'utilizzo 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 ulteriormente l'accessibilità salendo di un livello in più: 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 il gestore della sicurezza in fase di esecuzione o aggiungere una politica di sicurezza in un file jar che viene quindi sigillato per impedire modifiche.

Maggiori informazioni su come farlo in Java: Reflection Security

Di quale riflessione stai parlando?

In molti sistemi di riflessione, aggirare l'incapsulamento è una capacità esplicita che il codice deve ottenere e che non ha per impostazione predefinita.

Se sei preoccupato per l'incapsulamento, la soluzione semplice è semplicemente non utilizzare un sistema di riflessione che non lo preservi.

In Python non ci sono modificatori di accesso. La convenzione prevede il prefisso con un carattere di sottolineatura dei metodi e delle variabili a cui non si prevede di accedere dall'esterno della classe. Tecnicamente ti impedisce di accedere a tale campo da una classe di terze parti? Affatto; ma se lo fai, sei da solo e corri il rischio di rompere qualcosa, senza poter incolpare l'altra classe.

In C #, esistono modificatori di accesso, ma sono ancora solo una convenzione, quella che viene applicata da un compilatore, ma è comunque una convenzione. Ciò significa che tecnicamente, è ancora possibile accedere e modificare le variabili private, tramite Reflection o manomettendo direttamente la memoria (come i game trainer ). La conseguenza è esattamente la stessa: se le variabili della tua classe vengono modificate tramite Reflection da un'altra classe o tramite manomissione della memoria da un'altra applicazione e si rompe qualcosa nella tua classe, non è colpa tua.

Nota che questo, ovviamente, crea problemi di sicurezza in cui una terza parte può accedere ai tuoi dati; qualcosa che porta a varianti crittografate di una stringa e strutture di dati simili. Ma proteggere il tuo codice da tale utilizzo è più legato al sistema operativo e alle restrizioni di accesso a livello di codice e non ha nulla a che fare con Reflection in sé.