Devo affrontare la situazione in cui i metodi privati ​​sono chiamati attraverso la riflessione?


12

Quando si crea una libreria, è necessario assicurarsi che i metodi privati ​​debbano funzionare come previsto quando non vengono chiamati da altri metodi della stessa classe, ma da un'altra libreria tramite la riflessione ?

Ad esempio, se un metodo privato private DoSomething(int number)prevede che:

  • number è un numero intero diverso da zero positivo e:
  • una variabile privata string abcnon è nulla e non è una stringa vuota,

e completamente, brutto fallisce se queste due condizioni non sono abbinati, devo gestire tali fallimenti anche se so che tutti i metodi della classe saranno always¹ assegnare un valore non vuoto per abcprima di chiamare DoSomething, e passare un diverso da zero intero positivo a questo metodo?

In altre parole, il codice che non è protetto dalle chiamate non sicure attraverso la reflection può essere considerato come un codice di bassa qualità o appartiene al chiamante che utilizza la reflection per garantire che la chiamata non interrompa nulla?

Nota: la mia domanda copre solo un set standard di librerie. Questo non copre il codice che deve essere altamente sicuro (cioè quando qualcuno potrebbe essere interessato usando la riflessione per far sì che si comporti in modo imprevisto o si blocchi).


¹ Perché la classe è documentata correttamente, perché ci sono abbastanza test unitari per essere sicuri che nessun altro sviluppatore non infrange questo metodo, ecc.


le classi derivate saranno in grado di chiamare i metodi privati?
oenone,

Risposte:


16

Contrassegnando il tuo metodo come privato hai stabilito le tue intenzioni e un contratto. Usando la riflessione un codice cliente può scegliere di rompere con questo contratto e di conseguenza dovrà sopportarne le conseguenze. La stessa cosa accade con i protocolli, per far funzionare le regole devono essere seguite o succederanno cose brutte.

Lo stesso problema può verificarsi con altri linguaggi come il C ++ in cui ho visto cose del genere

#define private public

In breve: NON è necessario affrontare queste situazioni, il chiamante dovrebbe conoscerlo meglio.


3
Ho visto persone lanciare classi su (unsigned char *) e scrivere direttamente sull'offset di memoria di una variabile membro che vogliono cambiare. I miei occhi sanguinavano.
Shawn D.

6
Vorrei aggiungere che è sostanzialmente impossibile proteggere la tua classe da pericoloso codice privilegiato . Se in qualche modo riesci a proteggerti dall'uso inappropriato della riflessione, qualcuno troverà un modo diverso di rovinare la tua giornata, possibilmente semplicemente sovrascrivendo direttamente la memoria del processo. La codifica difensiva alla fine raggiunge un punto di rendimenti decrescenti e la riflessione è ben oltre quel punto.
Aaronaught,

5

Se qualcuno sta usando la riflessione per chiamare i tuoi metodi privati, è un segno che qualcuno sta facendo qualcosa di sbagliato. O sta usando il codice in un modo per cui non è stato progettato, oppure stai nascondendo troppo il funzionamento interno e smorzando l'API.

Ma sembra che tu non sia ancora nemmeno a quel punto e stai solo cercando di essere preventivo. Quindi la mia opinione è: non preoccuparti. Un metodo privato dovrebbe essere considerato off-limits; se qualcuno viola deliberatamente quei limiti, allora è un loro problema se le cose esplodono.


0

Bene, è sempre una buona idea convalidare le variabili non locali prima di usarle, ma a parte questo non me ne preoccuperei. Come hanno detto gli altri, hai stabilito le tue intenzioni rendendo il metodo privato in primo luogo; chiunque lo chiami al di fuori della tua classe non ha garanzie. Quando lavoro in Java, non inserisco nemmeno commenti javadoc sui miei metodi privati, perché non voglio che altri sviluppatori sappiano nemmeno che sono lì.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.