How could Reflection not lead to code smells?

Question

I come from low level languages - C++ is the highest level I program in.

Recently I came across Reflection, and I just cannot fathom how it could be used without cod

Answer 1

The idea behind this was to be able to query any GUI objects properties, to provide them in a GUI to get customized and preconfigured. Now it's uses have been extended and proved to be feasible.

EDIT: spelling

Answer 2

Reflection is most commonly used to circumvent the static type system, however it also has some interesting use cases:

Let's write an ORM!

If you're familiar with NHibernate or most other ORMs, you write classes which map to tables in your database, something like this:

// used to hook into the ORMs innards
public class ActiveRecordBase
{
    public void Save();
}

public class User : ActiveRecordBase
{
    public int ID { get; set; }
    public string UserName { get; set; }
    // ...   
}

How do you think the Save() method is written? Well, in most ORMs, the Save method doesn't know what fields are in derived classes, but it can access them using reflection.

Its wholly possible to have the same functionality in a type-safe manner, simply by requiring a user to override a method to copy fields into a datarow object, but that would result in lots of boilerplate code and bloat.

Stubs!

Rhino Mocks is a mocking framework. You pass an interface type into a method, and behind the scenes the framework will dynamically construct and instantiate a mock object implementing the interface.

Sure, a programmer could write the boilerplate code for the mock object by hand, but why would she want to if the framework will do it for her?

Metadata!

We can decorate methods with attributes (metadata), which can serve a variety of purposes:

[FilePermission(Context.AllAccess)]    // writes things to a file
[Logging(LogMethod.None)]              // logger doesn't log this method
[MethodAccessSecurity(Role="Admin")]   // user must be in "Admin" group to invoke method
[Validation(ValidationType.NotNull, "reportName")] // throws exception if reportName is null
public void RunDailyReports(string reportName) { ... }

You need to reflect over the method to inspect the attributes. Most AOP frameworks for .NET use attributes for policy injection.

Sure, you can write the same sort of code inline, but this style is more declarative.

Let's make a dependency framework!

Many IoC containers require some degree of reflection to run properly. For example:

public class FileValidator
{
    public FileValidator(ILogger logger) { ... }
}

// client code
var validator = IoC.Resolve<FileValidator>();

Our IoC container will instantiate a file validator and pass an appropriate implementation of ILogger into the constructor. Which implementation? That depends on how its implemented.

Let's say that I gave the name of the assembly and class in a configuration file. The language needs to read name of the class as a string and use reflection to instantiate it.

Unless we know the implementation at compile time, there is no type-safe way to instantiate a class based on its name.

Late Binding / Duck Typing

There are all kinds of reasons why you'd want to read the properties of an object at runtime. I'd pick logging as the simplest use case -- let say you were writing a logger which accepts any object and spits out all of its properties to a file.

public static void Log(string msg, object state) { ... }

You could override the Log method for all possible static types, or you could just use reflection to read the properties instead.

Some languages like OCaml and Scala support statically-checked duck-typing (called structural typing), but sometimes you just don't have compile-time knowledge of an objects interface.

Or as Java programmers know, sometimes the type system will get your way and require you to write all kinds of boilerplate code. There's a well-known article which describes how many design patterns are simplified with dynamic typing.

Occasionally circumventing the type system allows you to refactor your code down much further than is possible with static types, resulting in a little bit cleaner code (preferably hidden behind a programmer friendly API :) ). Many modern static languages are adopting the golden rule "static typing where possible, dynamic typing where necessary", allowing users to switch between static and dynamic code.

Answer 3

Plugins are a great example.

Tools are another example - inspector tools, build tools, etc.

Answer 4

I will give an example of a c# solution i was given when i started learning.

It contained classes marked with the [Exercise] attribute, each class contained methods which were not implemented (throwing NotImplementedException). The solution also had unit tests which all failed.

The goal was to implement all the methods and pass all the unit tests.

The solution also had a user interface which it would read all class marked with Excercise, and use reflection to generate a user interface.

We were later asked to implement our own methods, and later still to understand how the user interface 'magically' was changed to include all the new methods we implemented.

Extremely useful, but often not well understood.

Answer 5

Without reflection no plugin architecture will work!

Answer 6

As mentioned above, reflection is mostly used to implement code that needs to deal with arbitrary objects. ORM mappers, for instance, need to instantiate objects from user-defined classes and fill them with values from database rows. The simplest way to achieve this is through reflection.

Actually, you are partially right, reflection is often a code smell. Most of the time you work with your classes and do not need reflection- if you know your types, you are probably sacrificing type safety, performance, readability and everything that's good in this world, needlessly. However, if you are writing libraries, frameworks or generic utilities, you will probably run into situations best handled with reflection.

This is in Java, which is what I'm familiar with. Other languages offer stuff that can be used to achieve the same goals, but in Java, reflection has clear applications for which it's the best (and sometimes, only) solution.