Besides serialization, what would be the legitimate uses of reflection to access private members?

Reflection can be used to access just about any object's internals, which is kind of not cool. I tried to list the legitimate uses of it, but in the end only serialization came to my mind.

What other (legitimate) uses can you find to using reflection in order to access otherwise inaccessible members?

EDIT I mean stuff you can't开发者_如何学C do if you don't have reflection.

---

Unit testing comes to mind. If you want to test a private method but not expose it or use the InternalsVisibleToAttribute.

---

One is persisting objects to a DB. E.g. Hibernate does use reflection, and in some cases e.g. the object's ID might be a private member, with private setter/getter, because it is of no use in the Java domain. However it is needed in the DB, so Hibernate sets/gets it in the background, and uses it for determining object identity.

Another is writing the initial unit tests for badly designed legacy code, where you can't just start refactoring since you have no unit tests to safeguard yourself. In such cases, if other means (described in Working Effectively with Legacy Code) can't help you, reflection may be the last resort to start working towards maintainable code.

---

I guess one big area where it is used is in the context of managed environment, that is, when an framework or environment is supposed to provide some facilities and might require to access to private data.

Public/private access modifier is a concern at the application design level and a field shouldn't be turned public for the sake of making a framework happy. Examples include then framework like Hibernate which manages object persistence, dependency injection framework which can inject data in private field, or more generally application server which work regardless of the access modifier.

Even more generally, this fall into the umbrella of meta-programming. Some code inspects and modifies other objects dynamically without knowing their structure upfront.

---

Profiling or monitoring can be useful reasons to use reflection to private members and functions. For example, if you want to know how often a database connection is actually made, you can monitor access to a private SqlConnection.

This can better be done with AOP, but, if trying to get AOP to be acceptable is too difficult politically, then reflection can help out while you are in development.

---

You can also use reflection to invoke the methods based upon input type parameter ( like enum), thus essentially replacing a switch statement.

for example:

enter code here

   public class Test
   {
    public enum Status
    {
      Add,
      Delete,
      Update
    }

    public void Save(Status status)
    {
          //use reflection to obtain corresponding method
           MethodInfo method = this.GetType().GetMethod(status.ToString(),BindingFlags.NonPublic | BindingFlags.Instance);
         //Invoke method here

    }
    //you don't want to expose these methods
    private void Add()
    {

    }
    private void Delete()
    {

    }
    private void Update()
    {

    }
}

---

Debugging and profiling come to mind immediately -- they need to be able to get a more complete view of the internals of objects.

Garbage collection is another -- yes, the JVM has a garbage collector built in, but someone has to write that code and while most JVMs aren't written in java, there's no reason they couldn't be.