I understand the reflection API (in c#) but I am not sure in what situation would I use it. What are some patterns - anti-patterns for using reflection?
The prime place I use reflection: Pulling a type out of a database.
I have a class that needs to know which library to call. Keep in mind that as new tools are added to the list, the class needs to recognize the new tools without a recompile, so a switch statement is out of the question.
Instead, I store the reflection string in the DB that tells the class to "create one of these..." Since I (the programmer) always ensure that the class is derived from a single base class, the idea works. It's clean and efficient.
But I agree that if you use reflection for more than these "auto-generated code" scenarios, then you could be opening yourself up for a world of hurt when it comes to maintaining the code in the future.
(enter voice of wise, old sage)
Reflection comes with incredible power... use the power with wisdom.
I personaly don't use it a lot. I tend to use it when I don't have a different way to code something.
Here is an simple example:
public static void LogException(Exception exc, string source)
{
try
{
// Logic for logging exceptions
}
catch(Exception ex)
{
//If logging fails for some reason
//then we still log it using reflection
LogException(ex, "Error while logging an exception");
}
}
The only place I've used the Reflection stuff in C# was in factory patterns, where I'm creating objects (in my case, network listeners) based on configuration file information. The configuration file supplied the location of the assemblies, the name of the types within them, and any additional arguments needed. The factory picked this stuff up and created the listeners based on that.
I most often use it when I need to break somebody else's (usually the framework's) encapsulation. That is, I need to change some private field, or call a private method, or create an instance of some internal class in a library I have no power to change. A good example is the code in my answer to this question. In this case, the behavior of the framework method ServiceBase.Run was unacceptable, so I used reflection to do the same thing it does in a more acceptable manner.
Reflection has many other uses, though, including duck typing, working with attributes, and late binding.
I use reflection a fair amount in my unit tests, especially when the things I'm checking are anonymous types. I've also used it as a way to easily clone/copy model objects. Rather than write the code to do this for every model object, I can easily create an object of a particular type using reflection, interrogate the incoming object's public properties and invoke the settors on the cloned objects corresponding properties. I also use it with designer generated classes that implement the same method signatures, but don't have an associated interface. In those cases, I can interrogate the object to see if it has the required method and invoke it if it does. LINQ2SQL entities are like this so in my fake data context wrapper OnSubmit method I use reflection to get the OnValidate method and invoke it for unit testing.
When you want to improve performance of late-bound objects. You can emit the code necessary to call bound types directly, and then call through your emitted method. Although you cannot perform calls as speedily as with early binding, you will perform better than late binding.