2011-12-23 14 views
7

Sto usando java. Lo so usando il modificatore di accesso privato che possiamo limitare. Ma usando l'API Reflection posso accedere alla variabile anche al di fuori della classe. Allora, qual è l'uso del modificatore privato qui?come limitare la variabile per non accedere al di fuori della classe in java?

+0

Per impostazione predefinita è possibile accedere ai campi privati ​​tramite riflessione? –

+0

Sì. E non credo ci sia un modo semplice per dire a Java "nessuna riflessione sui miei campi privati". – user949300

risposta

2

Poiché la riflessione interrompe l'incapsulamento. È possibile impedire l'uso dell'API di riflessione se l'applicazione è in esecuzione in un ambiente di sicurezza gestito. Vedi Java Security Manager

8

private impedisce l'accesso da altre classi tramite Java. Tuttavia, usando JNI o ​​una libreria puoi fare le cose in modo diverso. È possibile impedire la riflessione con un responsabile della sicurezza, ma raramente è necessario.

Nota: alcune librerie come la serializzazione devono essere in grado di accedere ai campi privati ​​per funzionare.

+0

+1. Per l'OP, si prega di notare che prevenire la riflessione interromperà l'interoperabilità con molte librerie Java che si potrebbe desiderare di utilizzare. – Perception

+0

@Perception e alcune delle cose che le librerie fanno con la riflessione (creare costruttori senza argomenti che non esistono, quindi rottura finale, ecc.) Sono cambiamenti potenzialmente estremi nel codice. Molte volte chiudo gli occhi e prego che stiano facendo le cose per bene. :-) – user949300

+0

@ user949300 - sicuramente. Però, puoi immaginare come sarebbe una libreria come Hibernate senza la capacità di riflettere e le classi di byte engineer? – Perception

1

allora che cosa è l'uso del modificatore privato qui

Il modificatore private non è un meccanismo di sicurezza; è (una parte di) un meccanismo di incapsulamento. Nascondere gli interni di un oggetto dal consumo pubblico aiuta a mantenere gli oggetti in uno stato coerente e utilizzabile, fornendo al contempo commenti su quali parti di un oggetto compongono l'interfaccia pubblica (e può essere invocato per non cambiare).

Certo, gli utenti possono utilizzare la riflessione per accedere ai dati nei campi private, ma sapranno che stanno facendo qualcosa che non è supportato dalla libreria.

0

Non sono esperto in materia di sicurezza Java, ma penso che sia necessario fornire il proprio SecurityManager e sovrascrivere checkMemberAccess(). ad esempio, per evitare ogni riflessione

public void checkMemberAccess(Class<?> clazz, int which) throws AccessControlException { 

     if (which != Member.PUBLIC) { 
      throw new AccessControlException("No reflection on non-public fields allowed"); 
     } 
    } 

Ovviamente, nel mondo reale, si potrebbe voler controllare solo per un certo sottoinsieme di classi "importanti" nel primo argomento. E, come notato in molte altre risposte, ciò causerà problemi a molte librerie di terze parti.

Problemi correlati