Are there problems with using Reflection?

Question

I don't know why, but I always feel like I am "cheating" when I use reflection - maybe it is because of the performance hit I know I am taking.

Part of me says, if it is part of the language you are using and it can accomplish what you are trying to do, then why not use it. The other part of me says, there has to be a way I can do this without using reflection. I guess maybe it depends on the situation.

What are the potential issues I need to look out for when using reflection and how concerned should I be about them? How much effort is it worth spending to try to find a more conventional solution?

Answer 1

No, it's not cheating - it is a way to solve problems in some programming languages.

Now, it is often not the best (cleanest, simplest, easiest to maintain) solution. If there is a better way, use that one indeed. However, sometimes there isn't. Or if there is, it is just so much more complex, involving a lot of code duplication etc. which makes it infeasible (difficult to maintain in the long run).

Two examples from our current project (Java):

• some of our testing tools use reflection to load configuration from XML files. The class to be initialized has specific fields, and the config loader uses reflection to match the XML element named fieldX to the appropriate field in the class, and to initialize the latter. In some cases, it can build a simple GUI dialog box out of the identified properties on the fly. Without reflection, this would take hundreds of lines of code across several applications. So reflection helped us put together a simple tool quickly, without much fuss, and enabled us to focus on the important part (regression testing our web app, analysing server logs, etc.) rather than the irrelevant.
• one module of our legacy web app was meant to export/import data from DB tables to Excel sheets and back. It contained a lot of duplicated code, where of course the duplications were not exactly the same, some of them contained bugs etc. Using reflection, introspection and annotations, I managed to eliminate most of the duplication, cutting down the amount of code from over 5K to below 2.4K, while making the code more robust and way easier to maintain or extend. Now that module ceased to be a problem to us - thanks to the judicious use of reflection.

The bottom line is, like any powerful tool, reflection too can be used to shoot yourself in the foot. If you learn when and how (not) to use it, it can bring you elegant and clean solutions to otherwise difficult problems. If you abuse it, you can turn an otherwise simple problem into a complex and ugly mess.

Answer 2

It's not cheating. But it is usually a bad idea in production code for at least the following reasons:

• You lose compile-time type safety - it's helpful to have the compiler verify that a method is available at compile time. If you are using reflection, you'll get an error at runtime which might affect end users if you don't test well enough. Even if you do catch the error, it will be be more difficult to debug.
• It causes bugs when refactoring - if you are accessing a member based on its name (e.g. using a hard-coded string) then this won't get changed by most code refactoring tools and you'll instantly have a bug, which might be quite hard to track down.
• Performance is slower - reflection at runtime is going to be slower than statically compiled method calls/variable lookups. If you're only doing reflection occasionally then it won't matter, but this can become a performance bottleneck in cases where you are making calls via reflection thousands or millions of times per second. I once got a 10x speedup in some Clojure code simply by eliminating all reflection, so yes, this is a real issue.

I'd suggest limiting the use of reflection to the following cases:

• For quick prototyping or "throwaway" code when it is the simplest solution
• For genuine reflection use cases, e.g. IDE tooling that allows a user to examine the fields/methods of an arbitrary object at runtime.

In all other cases I'd suggest figuring out an approach that avoids reflection. Defining an interface with the appropriate method(s) and implementing it on the set of classes you want to call the method(s) on is usually sufficient to solve most simple cases.

Answer 3

Reflection is just another form of meta-programming, and just as valid, as the type-based parameters that you see in most languages these days. Reflection is powerful and generic, and reflective programs are a high order of maintainability (when used correctly, of course) and more so than purely object-orientated or procedural programs. Yes, you pay a performance price- but I'd gladly go for a slower program that's more maintainable in many, or even most, cases.

Answer 4

Reflection is an awesome tool if you are a library author, and thus have no influence over the incoming data. A combination of reflection and meta-programming can allow your library to work seamlessly with arbitrary callers, without them having to jump through hoops of code-generation etc.

I do try to discourage from reflection in application code, though; at the app layer you should be using different metaphors - interfaces, abstraction, encapsulation etc.

Answer 5

Surely it all depends on what are you trying to achieve.

For example, I wrote a media checker application that uses dependency injection to determine what sort of media (MP3 files or JPEG files) to check. The shell needed to display a grid containing the pertinent information for each type, but it had no knowledge of what it was going to display. This is defined in the assembly that reads that type of media.

Therefore I had to use reflection to get the number of columns to display and their types and names so I could set the grid up correctly. It also meant that I could update the injected library (or create a new one) without changing any other code or configuration file.

The only other way would have been to have a configuration file that would need to be updated when I switched the type of media being checked. This would have introduced another point of failure for the application.

Answer 6

Reflection is fantastic for building tools for developers.

As it allows your build environment to inspect the code and potentially generate the correct tools to manipulate/init inspect the code.

As a general programming technique it can be useful but is more brittle than most people imagine.

One really development use for reflection (IMO) is that it makes writing a generic streaming library very simple (as long as your class description never changes (then it becomes a very brittle solution)).

Answer 7

Use of reflection is often harmful in OO languages if not used with great awareness.

I have lost count of how many bad questions I have seen on StackExchange sites where

1. The language in use is OO
2. The author wants to find out which type of object has been passed in and then call one of its methods
3. The author refuses to accept that reflection is the wrong technique and accuses anybody who points this out as "not knowing how to help me"

Here are typical examples.

Most of the point of OO is that

1. You group functions which know how to manipulate a structure/concept with the thing itself.
2. In any point of your code you should know enough about an object's type to know what relevant functions it has and ask it to call its particular version of those functions.
3. You ensure the truth of the previous point by specifying the correct input type for every function and having each function know no more (and do no more) than is relevant.

If at any point in your code, point 2 is not valid for an object you have been passed then one or more of these is true

1. The wrong input is being fed in
2. Your code is poorly structured
3. You have no idea what the hell you are doing.

Poorly skilled developers simply do not get this and believe that they can be passed anything in any part of their code and do what they want from a (hard-coded) set of possibilities. These idiots use reflection a lot.

For OO languages, reflection should only be needed in meta activity (class loaders, dependency injection etc). In those contexts, reflection is needed because you are providing a generic service to assist the manipulation/configuration of code which you know nothing about for a good and legitimate reason. In almost any other situation, if you are reaching for reflection then you are doing something wrong and you need to ask yourself why this piece of code does not know enough about the object that has been passed to it.

Answer 8

An alternative, in cases where the domain of the reflected classes is well-defined, is to use reflection along with other metadata to generate code, instead of using reflection at runtime. I do this using FreeMarker/FMPP; there are lots of other tools to choose from. The advantage to this is that you end up with "real" code that can easily be debugged, etc.

Depending on the situation, this can help you make a lot faster code - or just a lot of code bloat. It avoids the disadvantages of reflection:

• loss of compile-time type safety
• bugs due to refactoring
• slower performance

mentioned earlier.

If reflection feels like cheating, it may be because you're basing it on a lot of guesswork that you're not sure of, and your gut is warning you that this is risky. Be sure to provide a way to enhance the metadata inherent in reflection with your own metadata, where you can describe all the quirks and special cases of the real-world classes you may encounter.

Answer 9

It isn't cheating, but like any tool, it should be used for what it is intended to solve. Reflection, by definition, allows you to inspect and modify code through code; if that is what you need to do, then reflection is the tool for the job. Reflection is all about meta-code: Code that targets code (as opposed to regular code, which targets data).

An example of good reflection use is generic web service interface classes: A typical design is to separate protocol implementation from payload functionality. So then you have one class (let's call it T) that implements your payload, and another that implements the protocol (P). T is fairly straightforward: for every call you want to make, simply write one method that does whatever it is supposed to do. P, however, needs to map web service calls to method calls. Making this mapping generic is desirable, because it avoids redundancy, and makes P highly reusable. Reflection provides the means to inspect class T at runtime and call its methods based on strings passed into P through the web service protocol, without any compile-time knowledge of class T. Using the 'code about code' rule, one can argue that class P has the code in class T as part of its data.

However.

Reflection also gives you tools to get around restrictions of the language's type system - theoretically, you could pass all parameters as type object, and call their methods through reflections. Voilà, the language that is supposed to enforce strong static typing discipline now behaves like a dynamically typed language with late binding, only that the syntax is far more elaborate. Every single instance of such a pattern I've seen so far has been a dirty hack, and invariably, a solution within the language's type system would have been possible, and it would have been safer, more elegant, and more efficient in all regards.

A few exceptions exist, such as GUI controls that can be data-bound to various non-related types of data sources; mandating that your data implement a certain interface just so you can data-bind it isn't realistic, and neither is having the programmer implement an adaptor for each type of data source. In this case, using reflection to detect the type of data source and adjusting the data binding is a more useful choice.

Answer 10

One problem we have had with Reflection is when we added Obfuscation to the mix. All classes get new names and suddenly loading a class or function by its name stops working.

Answer 11

It totally depends. An example of something that would be hard to do without reflection would be to replicate ObjectListView. It also generates IL code on the fly.

Answer 12

Reflection is the primary method of creating convention-based systems. I would not be surprised to find it is in use heavily inside most MVC frameworks. It's a major component in ORMs. Chances are, you're already using components built with it every day.

The alternative for such a use is configuration, which has its own set of drawbacks.

Answer 13

Reflection can achieve things that simply can't be done practically otherwise.

For example, consider how to optimize this code:

int PoorHash(char Operator, int seed, IEnumerable<int> values) {
    foreach (var v in values) {
        seed += 1;
        switch (char) {
            case '+': seed += v; break;
            case '^': seed ^= v; break;
            case '-': seed -= v; break;
            ...
        }
        seed *= 3;
    }
    return seed;
}

There's an expensive test smack in the middle of the inner loop, but extracting it requires rewriting the loop once for each operator. Reflection allows us to get performance on par with extracting that test, without repeating the loop a dozen times (and thereby sacrificing maintainability). Just generate and compile the loop you need on the fly.

I have actually done this optimization, although it was a bit more complicated of a situation, and the results were amazing. An order of magnitude improvement in performance and fewer lines of code.

(Note: I initially tried the equivalent of passing in a Func instead of a char, and it was slightly better, but not nearly the 10x reflection achieved.)

Answer 14

No way is it cheating... Rather, it empowers application servers to run the classes made by the user with the name of their choice, hence providing flexibility to the user, not cheating them.

And if you want to see the code of any .class file (in Java) then there are several decompilers available free of charge!