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

It's very useful for dependency injection. You can explore loaded assemblies types implementing a given interface with a given attribute. Combined with proper configuration files, it proves to be a very powerful and clean way of adding new inherited classes without modifying the client code.

Also, if you are doing an editor that doesn't really care about the underlying model but rather on how the objects are structured directly, ala System.Forms.PropertyGrid)

Answer 2

Very simple example in Python. Suppose you have a class that have 3 methods:

class SomeClass(object):
    def methodA(self):
       # some code
    def methodB(self):
       # some code
    def methodC(self):
       # some code

Now, in some other class you want to decorate those methods with some additional behaviour (i.e. you want that class to mimic SomeClass, but with an additional functionality). This is as simple as:

class SomeOtherClass(object):
    def __getattr__(self, attr_name):
        # do something nice and then call method that caller requested
        getattr(self.someclass_instance, attr_name)()

Answer 3

Unit testing software and frameworks like NUnit use reflection to get a list of tests to execute and executes them. They find all the test suites in a module/assembly/binary (in C# these are represented by classes) and all the tests in those suites (in C# these are methods in a class). NUnit also allows you to mark a test with an expected exception in case you're testing for exception contracts.

Without reflection, you'd need to specify somehow what test suites are available and what tests are available in each suite. Also, things like exceptions would need to be tested manually. C++ unit testing frameworks I've seen have used macros to do this, but some things are still manual and this design is restrictive.

Answer 4

With reflection, you can write a small amount of domain independent code that doesn't need to change often versus writing a lot more domain dependent code that needs to change more frequently (such as when properties are added/removed). With established conventions in your project, you can perform common functions based on the presence of certain properties, attributes, etc. Data transformation of objects between different domains is one example where reflection really comes in handy.

Or a more simple example within a domain, where you want to transform data from the database to data objects without needing to modify the transformation code when properties change, so long as conventions are maintained (in this case matching property names and a specific attribute):

    ///--------------------------------------------------------------------------------
    /// <summary>Transform data from the input data reader into the output object.  Each
    /// element to be transformed must have the DataElement attribute associated with
    /// it.</summary>
    ///
    /// <param name="inputReader">The database reader with the input data.</param>
    /// <param name="outputObject">The output object to be populated with the input data.</param>
    /// <param name="filterElements">Data elements to filter out of the transformation.</param>
    ///--------------------------------------------------------------------------------
    public static void TransformDataFromDbReader(DbDataReader inputReader, IDataObject outputObject, NameObjectCollection filterElements)
    {
        try
        {
            // add all public properties with the DataElement attribute to the output object
            foreach (PropertyInfo loopInfo in outputObject.GetType().GetProperties())
            {
                foreach (object loopAttribute in loopInfo.GetCustomAttributes(true))
                {
                    if (loopAttribute is DataElementAttribute)
                    {
                        // get name of property to transform
                        string transformName = DataHelper.GetString(((DataElementAttribute)loopAttribute).ElementName).Trim().ToLower();
                        if (transformName == String.Empty)
                        {
                            transformName = loopInfo.Name.Trim().ToLower();
                        }

                        // do transform if not in filter field list
                        if (filterElements == null || DataHelper.GetString(filterElements[transformName]) == String.Empty)
                        {
                            for (int i = 0; i < inputReader.FieldCount; i++)
                            {
                                if (inputReader.GetName(i).Trim().ToLower() == transformName)
                                {
                                    // set value, based on system type
                                    loopInfo.SetValue(outputObject, DataHelper.GetValueFromSystemType(inputReader[i], loopInfo.PropertyType.UnderlyingSystemType.FullName, false), null);
                                }
                            }
                        }
                    }
                }
            }

            // add all fields with the DataElement attribute to the output object
            foreach (FieldInfo loopInfo in outputObject.GetType().GetFields(BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.GetField | BindingFlags.Instance))
            {
                foreach (object loopAttribute in loopInfo.GetCustomAttributes(true))
                {
                    if (loopAttribute is DataElementAttribute)
                    {
                        // get name of field to transform
                        string transformName = DataHelper.GetString(((DataElementAttribute)loopAttribute).ElementName).Trim().ToLower();
                        if (transformName == String.Empty)
                        {
                            transformName = loopInfo.Name.Trim().ToLower();
                        }

                        // do transform if not in filter field list
                        if (filterElements == null || DataHelper.GetString(filterElements[transformName]) == String.Empty)
                        {
                            for (int i = 0; i < inputReader.FieldCount; i++)
                            {
                                if (inputReader.GetName(i).Trim().ToLower() == transformName)
                                {
                                    // set value, based on system type
                                    loopInfo.SetValue(outputObject, DataHelper.GetValueFromSystemType(inputReader[i], loopInfo.FieldType.UnderlyingSystemType.FullName, false));
                                }
                            }
                        }
                    }
                }
            }
        }
        catch (Exception ex)
        {
            bool reThrow = ExceptionHandler.HandleException(ex);
            if (reThrow) throw;
        }
    }

Answer 5

One usage not yet mentioned: while reflection is generally thought of as "slow", it's possible to use Reflection to improve the efficiency of code which uses interfaces like IEquatable<T> when they exist, and uses other means of checking equality when they do not. In the absence of reflection, code that wanted to test whether two objects were equal would have to either use Object.Equals(Object) or else check at run-time whether an object implemented IEquatable<T> and, if so, cast the object to that interface. In either case, if the type of thing being compared was a value type, at least one boxing operation would be required. Using Reflection makes it possible to have a class EqualityComparer<T> automatically construct a type-specific implementation of IEqualityComparer<T> for any particular type T, with that implementation using IEquatable<T> if it is defined, or using Object.Equals(Object) if it is not. The first time one uses EqualityComparer<T>.Default for any particular type T, the system will have to go through more work than would be required to test, once, whether a particular type implements IEquatable<T>. On the other hand, once that work is done, no more run-time type checking will be required since the system will have produced a custom-built implementation of EqualityComparer<T> for the type in question.

Answer 6

Without reflection you often have to repeat yourself a lot.

Consider these scenarios:

• Run a set of methods e.g. the testXXX() methods in a test case
• Generate a list of properties in a gui builder
• Make your classes scriptable
• Implement a serialization scheme

You can't typically do these things in C/C++ without repeating the whole list of affected methods and properties somewhere else in the code.

In fact C/C++ programmers often use an Interface description language to expose interfaces at runtime (providing a form of reflection).

Judicious use of reflection and annotations combined with well defined coding conventions can avoids rampant code repetition and increase maintainability.