Is reflection unhealthy?

Am I the only one who feels a bit dirty after writing code that uses reflection? Most programmers agree that strong typing is a good feature in programming languages, because it allows compilers to catch many kinds of programming errors before you run your program the first time.  But using reflection completely bypasses that security.

Reflection is useful for working around the type system when it gets in the way. For example say you want to write a universal object serializer. It needs to work on classes that haven’t even been defined yet, so there’s no way it can access the instance variables of those classes in a type-safe manner. Reflection provides a way to ask objects what instance variables they contain, the current values of those instance variables, and so on. There are countless applications – I don’t need to list them here. (There’s a good discussion on the Fog Creek discussion board.) But what’s interesting is how reflection subverts strong typing.

First, method invocations and any other operations performed using reflection are not typesafe:

MethodInfo methodInfo = myObject.GetType().GetMethod("MyMethod");
methodInfo.Invoke(myObject, new object[] {});

There is no way at compile time of protecting against a type error in that code sequence. Second, most programmers won’t be able to resist checking that methodInfo is non-null, to protect against a possible null pointer exception:

MethodInfo methodInfo = myObject.GetType().GetMethod("MyMethod");
if (methodInfo != null)
{
  methodInfo.Invoke(myObject, new object[] {});
}

That’s not a bad instinct. After all, who knows what kind of myObject might be passed to this code? But now we’ve subverted the type system twice. It can’t check that we’re calling the method correctly, and it can’t even check that we’re providing the right kind of object. If we provide the wrong kind of object, this code will simply do nothing, probably causing a mysterious, silent failure.

Let’s see, what other kinds of trouble can we get into? Say we refactor the code and change the name MyMethod to something else. A smart IDE can do this automatically for us – but it will miss the reflection-based calls since they are only visible to the IDE as character strings. What will our code example do in this case? It will fail mysteriously and silently again.

Reflection also undermines program correctness by encouraging the creation of implicit contracts. Normally if you want to create a clear contract between two classes, you create an interface. For example, if you have a strange kind of collection class which calls WriteAuditRecord() on each object that is added, you might define the collection to accept only contents of type Auditable, which would be an interface with a WriteAuditRecord() method. Anyone using the collection would get a compile-time type error if they attempted to compile code which inserts objects that do not support that method. That would lead them to read the documentation in the Auditable interface and learn about the contract between the classes. But you could also create a clever solution using reflection to check whether any inserted items support a WriteAuditRecord method, and if so call that method automatically. That would allow programmers to add items to the collection without changing their implementation to implement the Auditable interface. More flexible, right? Except that if a programmer accidentally misspells the method as WriteAudiRecord, it will not get called; another silent error that would normally have been caught by the typechecker. Or even spookier, programmers might not know about this special audit behavior and be surprised when their WriteAuditRecord() method gets called for no apparent reason.

I’d also like to take a poke at another sacred cow: attributes (or annotations if you’re a Java person). My main beef with these is that to use them, you need to use reflection. See above.

I’m not 100% against the use of reflection and annotations. They can be very useful when creating frameworks that need to work on any kind of object (e.g. for serialization and persistence, or for configuration systems like Spring) but my point is they should be used sparingly and you should take a shower afterward.