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 don't know if it is a pattern but I use reflection to generate SQL from DAO's class definitions.

Answer 3

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.

Answer 4

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.

Answer 5

I went for 2 years of development without understanding the purpose of reflection. It has very niche uses, but is extremely powerful when it is the right tool for the job.

I think what I'm trying to say is only use it when you are sure it's the only way to achieve what you want.

Answer 6

In one product I'm working on we use it a lot, but Reflection is a complex, slow beast. Don't go looking for places to use it just because it sounds fun or interesting. You'll use it when you run into a problem that can't be solved in any other way (dynamically loading assemblies for plug ins or frameworks, assembly inspection, factories where types ren't know at build, etc). It's certainly worth looking at reflection tutorials to see how it works, but don't fall into the trap of "having a hammer and everything looking like a nail." It's got very specialized use cases.

Answer 7

I use it in a case similar to that mentioned by Harper Shelby, in which a configuration file specifies at runtime which object to instantiate. In my particular case there's nothing as elaborate as a factory--only a set of classes that implement a common interface, and a simple function that reads the configuration file and creates the proper object, returning the interface.

Answer 8

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.

Answer 9

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.

Answer 10

I use it in a binary serializer (protobuf-net). I use reflection only to build the model - when it is used (i.e. during [de]serialization) it is using delegates etc for maximum performance.

I also used it (along with ComponentModel and Reflection.Emit) in HyperDescriptor, to build accelerated property access (~100x the speed of regular reflection).

And by necessity, you need to use reflection if you are building your own Expressions.

Answer 11

Use reflection as little as possible.

Answer 12

+1 on the factory pattern usage -- very powerful there.

Aside from the factory pattern, every time I've used it, I probably shouldn't have...

I've used it to dynamically load classes that implement certain interfaces (mine were menu items from assemblies) at startup and I really regret that usage. I wish I would've loaded from a config file (and later added a form that showed available interfaces to load). It's cool but terribly slow...

An anti-pattern is to use it access properties that class designers marked as private without knowing why they marked them as private. I've done this with the DataGridView WinForms control to unset a boolean variable so I could have a "companion" column move when its complement was moved. Once again, it's very cool but that code will fail horribly if a new release changes that private property (it very well could be gone in 3.0 or 3.5...).

Answer 13

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 14

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 15

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 16

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.