Nei corsi di programmazione OO, gli insegnanti ci dicono sempre di impostare i membri della classe in privato, a meno che non ci sia una buona ragione perché è più "sicuro".
In che modo impostare i membri su privato rende il programma più sicuro? Quali sono le potenziali minacce per l'impostazione pubblica dei membri della classe?
In realtà mettere un membro della classe pubblico o privato non ha nulla a che fare con la sicurezza. Questa risposta su StackOverflow lo descrive abbastanza bene:
Che cosa sono pubblici, privati e protetti nell'oggetto programmazione orientata?
Si noti inoltre che esistono linguaggi come Python in cui esiste solo una convenzione per avviare metodi privati con un carattere di sottolineatura. Tuttavia, ogni programmatore può ancora accedere a questo metodo da un'altra classe. Questa domanda StackOverflow copre abbastanza bene: Perché i metodi "privati" di Python non sono in realtà privato?
Ci sono situazioni specifiche e limitate in cui la visibilità del campo ha un impatto. Sto parlando di applet Java . Un'applet Java senza firma può solo eseguire interazioni di sistema limitate (nessun accesso ai file locali, nessuna connessione a server esterni eccetto quello che ha servito il codice dell'applet e così via). Queste restrizioni sono applicate attraverso un complesso framework di "permessi" che è implementato ... nel codice Java della libreria standard.
Se un'applet può accedere a campi privati di oggetti Java arbitrari da altri pacchetti, allora potrebbe interferire con gli oggetti e le tabelle che definiscono le autorizzazioni correnti per l'applet stessa. In effetti, il diritto di utilizzare l'API reflection su tutte le classi (incluse le classi di sistema) concede tecnicamente tutti i diritti sull'applet.
Questo non significa che le parole chiave di visibilità del campo come private o protected siano una funzionalità di sicurezza; significa che i progettisti di Sun / Oracle hanno utilizzato la visibilità sul campo per implementare e supportare un framework di sicurezza (e, a mio parere, avrebbero dovuto farlo diversamente, perché farlo in questo modo è come cercare di mantenere una lista nera di "chiamate pericolose" "su migliaia di possibili chiamate, ed è un lavoro molto duro, e l'apparizione ricorrente di exploit Java 0-day è una testimonianza della durezza di un simile approccio).
Per la maggior parte delle altre situazioni, i campi oggetto dovrebbero essere resi privati perché promuovono migliori pratiche di ingegneria del software, rendendo il codice che è più facile da mantenere (come tutte le regole, che ha eccezioni; occasionalmente , campo pubblico è un'idea migliore). Qui non c'è nulla su security ; si tratta di usabilità e manutenibilità .
Se dichiariamo i membri della classe come privati, è possibile accedervi solo all'interno della classe. Quindi, se guardiamo attraverso il punto di vista della sicurezza, dichiararlo come privato protegge i membri della classe.
Non è possibile accedere ai metodi membri utilizzando gli oggetti se sono dichiarati come privati.
Le variabili membro non sono accessibili se sono private.
Quindi nei programmi se devi mantenere alcuni valori come segreti, come chiavi di crittografia, altre credenziali, deve essere dichiarato come privato. In alcuni casi, se stai scrivendo un metodo per l'autenticazione, renderli privati ti sommerà un piccolo livello di sicurezza.
Leggi altre domande sui tag java .net attack-prevention programming