When do you use reflection? Patterns/anti-patterns

Question

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?

Answer 1

I'm not about to drop any patterns, but I would suggest that it's a good idea to avoid reflection until you actually need it. It's especially useful for interop and extensibility situations where you cannot control ahead of time the type of an object.

Answer 2

I find reflection (combined with runtime class loading) indispensable for implementing plugins:

1. search for jars / assemblies in a known location
2. enumerate jars / assemblies for classes supporting the interface your plugin supports
3. instantiate the plugin at runtime

Answer 3

Reflection allows you to solve problems that would otherwise require you to duplicate code. If you find yourself copying and pasting code, and can't see how an OO pattern can help, maybe if you can call them, then the "r team" can help.

Only joking. I couldn't understand the point of reflection for ages. If you can write code to perform a job, why do you need to use reflection at all?

Say you have lots of GUI objects like Forms or 'table' objects. It binds to a business object like a Customer:

public class Customer
{
   public string FirstName;
   public string LastName;

}

Your users don't want to see the column headings 'FirstName' or 'LastName'. They want 'Christian Name' and Surname. You don't want to code the literal strings in all your GUI objects in case they change their minds to 'First Name' and 'Father's last name' (I know , crap example).

If you define your class using attributes:

public class Customer
{
   [Description("Christian Name")]
   public string FirstName;

   [Description("Surname")]
   public string LastName;

}

You can use reflection to pull out the column names. If you need to change the way all your GUI objects describe the customer object, you now do it in one place.

I am not aware of any anti-patterns. My advice is to jump in and try it. You will start to see all sorts of ways in which reflection gives you an elegant solution. Performance is often cited as a reason for not using relfection. There is a performance overhead with relfection but I would discount it unless you can prove the overhead is hurting an algorithm you need.

Answer 4

I have used reflection in a number of places. The main broad categories include:

1. Auto-generated GUIs (ie, a property editor). You can loop over the properties of an object and use a registry of UI element factories to build a form. I use attributes on properties to guide the UI creation.
2. Serialization. I have written serialization frameworks the use reflection to serialize and deserialize objects.
3. Web Services. Similar to serialization, I have used reflection to create and consume SOAP messages and also to generate WSDL.
4. Domain Specific Languages. Interpreted scripting languages will typically bind to objects and methods using reflection.
5. Debugging tools. Such tools can use reflection to examine the state of an object. Handy for creating log messages under fault conditions.

Patterns wise, I'm not sure what the patterns are. A common thread between all the uses is reference by name and late binding - you want to bind to a member at runtime. This is often the case when you dynamically load assemblies and do not know the types of objeccts you need to create/manipulate.

Using reflection is powerful, but it wont make you more popular at parties. Only use it where the coupling is intentionally weak. So weak that you expect it to break at runtime. A great example is data binding in WPF.

I'm unsure about anti-patterns, but surely it would relate to doing things at runtime that should be done at compile time...

Answer 5

I don't know if it is a pattern but I use reflection to generate SQL from DAO's class definitions.

Answer 6

There is no hard and fast rule. Basically, you don't use reflection without a good reason. Use reflection when you can't do what you want without it, or when your code would be much longer or more difficult to understand without reflection.