2009-03-10 14 views

risposta

60

Sì.

Type type = typeof(TheClass); 
FieldInfo info = type.GetField(name, BindingFlags.NonPublic | BindingFlags.Static); 
object value = info.GetValue(null); 

Questo è per un campo. Per una proprietà, modificare type.GetField in type.GetProperty. Puoi anche accedere a metodi privati ​​in modo simile.

+1

Potrebbe valere la pena notare che il campo statico può anche essere assegnato tramite 'info.SetValue (null, value)'. Ho usato questa risposta per impostare un valore su un campo statico. – IAbstract

-1

provare qualcosa di simile:

Type type = typeof(MyClass); 
MemberInfo[] members = type.GetMembers(BindingFlags.NonPublic | BindingFlags.Static); 

Vorrei pensare che è dovrebbe funzionare.

+0

MemberInfo non ha metodi 'GetValue (...)' o 'SetValue (...)'. I membri sono più spesso metodi/funzioni reali. – IAbstract

1

Se hai piena fiducia, si dovrebbe essere in grado di fare:

Type t = typeof(TheClass); 
FieldInfo field = t.GetField("myFieldName", BindingFlags.NonPublic | BindingFlags.Static); 
object fieldValue = field.GetValue(myObject); 

Tuttavia, se si esegue questo su un sistema senza la piena fiducia, la chiamata GetField fallirà, e questo non funzionerà.

5

Suppongo che qualcuno dovrebbe chiedere se questa è una buona idea o no? Crea una dipendenza dall'implementazione privata di questa classe statica. L'implementazione privata è soggetta a modifiche senza alcun preavviso dato alle persone che utilizzano Reflection per accedere all'implementazione privata.

Se le due classi devono funzionare insieme, valutare la possibilità di creare il campo interno e di aggiungere l'assembly della classe cooperante in un attributo [assembly: InternalsVisibleTo].

+1

Nel codice di produzione questa è generalmente una cattiva idea. Può tuttavia essere molto utile quando si esegue il test delle unità, perché è possibile scrivere test senza dover esporre campi che preferiresti mantenere privati. – AVee

+3

@AVee: per il test dell'unità, rendere il campo 'internal' e utilizzare' InternalsVisibleTo'. Meglio, i test unitari non dovrebbero testare l'implementazione, solo un comportamento corretto. In base al campo privato, ora il test unitario si interromperà se l'implementazione della classe cambia. –

+1

Sono d'accordo con la riflessione di @JohnSaunders come questa è molto fragile. Ci sono casi, tuttavia, in cui dovrebbe esistere un lavoro temporaneo - cioè il codice di produzione è già stato rilasciato, ma avevo bisogno di un'utilità speciale per eseguire alcuni test di accettazione. Ho potuto ottenere questo solo accedendo a un campo statico privato tramite la riflessione. Questo codice cambierà e la classe riflessa verrà modificata per consentire l'interazione richiesta dalla nuova utilità nella prossima versione. – IAbstract

Problemi correlati