Reflection: for frameworks only?

Question

Somebody that I work with and respect once remarked to me that there shouldn't be any need for the use of reflection in application code and that it should only be used in frameworks. He was speaking from a J2EE background and my professional experience of that platform does generally bear that out; although I have written reflective application code using Java once or twice.

My experience of Ruby on Rails is radically different, because Ruby pretty much encourages you to write dynamic code. Much of what Rails gives you simply wouldn't be possible without reflection and metaprogramming and many of the same techniques are equally as applicable and useful to your application code.

• Do you agree with the viewpoint that reflection is for frameworks only? I'd be interested to hear your opinions and experiences.

Answer 1

I disagree, my application uses reflection to dynamically create providers. I might also use reflection to control logic flow, if the logic is simple and doesn't warrant a more complicated pattern.

In C# I use reflection to grab attributes off Enumeration which help me determine how to display an enumeration to an end user.

Answer 2

I disagree, reflection is very useful in application code and I find myself using it quite often. Most recently, I had to use reflection to load an assembly (in order to investigate its public types) from just the path of the assembly.

Several opinions on this subject are expressed here...

http://stackoverflow.com/questions/37628/what-is-reflection-and-why-is-it-useful

Answer 3

Use reflection when there is no other way! This is a matter of performance!

If you have looked into .NET performance pitfalls before, it might not surprise you how slow the normal reflection is: a simple test with repeated access to an int property proved to be ~1000 times slower using reflection compared to the direct access to the property (comparing the average of the median 80% of the measured times).

See this: .NET reflection - performance

MSDN has a pretty nice article about When Should You Use Reflection?

Answer 4

If your problem is best solved by using reflection, you should use it.

(Note that the definition of 'best' is something learnt by experience :)

The definition of framework vs. application isn't all that black & white either. Sometimes your app needs a bit of framework to do its job well.

Answer 5

There's the old joke that any sufficiently sophisticated system written in a statically-typed language contains an incomplete, inferior implementation of Lisp.

Since your requirements tend to become more complicated as a project evolves, you often eventually find that the common idioms in statically-typed object systems eventually hit a wall. Sometimes reaching for reflection is the best solution.

I'm happy in dynamically-typed languages like Ruby, and statically-typed languages like C#, but the implicit reflection in Ruby often makes for simpler, easier-to-read code. (Depending on the metaprogramming magic required, sometimes harder to write).

In C#, I've found problems that couldn't be solved without reflection, because of information I didn't have until runtime. One example: When trying to manipulate some third-party code that generated proxies to Silverlight objects running in another process, I had to use reflection to invoke a specific strongly-typed "Generic" version of a method, because the marshalling required the caller to make an assumption about the type of the object in the other process was in order to extract the data we needed from it, and C# doesn't allow the "type" of the generic method invocation to be specified at run time (except with reflection techniques). I guess you could argue our tool was kind of a framework, but I could easily imagine a case in an ordinary application facing a similar problem.

Answer 6

Reflection makes DRY a lot easier. It's certainly possible to write DRY code without reflection, but it's often much more verbose.

If some piece of information is encoded in my program in one way, why wouldn't I use reflection to get at it, if that's the easiest way?

It sounds like he's talking about Java specifically. And in that case, he's just citing a special case of this: in Java, reflection is so wonky it's almost never the easiest way to do something. :-) In other languages like Ruby, as you've seen, it often is.

Answer 7

Reflection is definitely heavily used in frameworks, but when used correctly can help simplify code in applications.

One example I've seen before is using a JDK Proxy of a large interface (20+ methods) to wrap (i.e. delegate to) a specific implementation. Only a couple of methods were overridden using a InvocationHandler, the rest of the methods were invoked via reflection.

Reflection can be useful, but it is slower that doing a regular method call. See this reflection comparison.

Answer 8

Reflection in Java is generally not necessary. It may be the quickest way to solve a certain problem, but I would rather work out the underlying problem that causes you to think it's necessary in app code. I believe this because it frequently pushes errors from compile time to run time, which is always a Bad Thing for large enough software that testing is non-trivial.

Answer 9

I think the observation that there shouldn't be any need for the use of reflection in application code and that it should only be used in frameworks is more or less true.

On the spectrum of how coupled some piece of code are, code joined by reflection are as loosely coupled as they come.

As such, the code which is doing it's job via reflection can quite happily fulfil it's role in life knowing not-a-thing about the code which is using it.