Negative tive C # item43: avoid excessive reflection usage

Reflection is a powerful tool that enables us to write more dynamic software. through reflection, an application can add new components that are "not existing at application deployment, to complete the upgrade of new features, which is the biggest function of reflection.

Reflection is also a double-edged sword. It brings convenience while introducing complexity, which greatly increases the probability of a problem. When reflection is used, the C # type security is bypassed. The types of parameters and returned values received by the invoke method are system. Object. We must ensure that the correct type is used during runtime. Therefore, although reflection makes it easier to build dynamic programs, the possibility of program problems also increases, so we should not over-use reflection.

When we use reflection, there are usually three situations: Creating an object instance, calling an object method, and accessing object attributes.

First, let's take a look at how to create an object instance. After obtaining the object type, we can create a constructinfo object based on the Type name, and then call the invoke method of the object, get an object of the specified type. Let's look at the following code.

Code

  1 // Usage:Create a new object using reflection:
 2 Type t = typeof( MyType );
 3 MyType obj = NewInstance( t ) as MyType;
 4 
 5 
 6 // Example factory function, based on Reflection:
 7 object NewInstance( Type t )
 8 {
 9   // Find the default constructor:
10   ConstructorInfo ci = t.GetConstructor( new Type[ 0 ] );
11   if ( ci != null )
12     // Invoke default constructor, and return
13     // the new object.
14     return ci.Invoke( null );
15 
16   // If it failed, return null.
17   return null;
18 }

It can be seen that the above Code is of a weak type and there will be no problems during compilation. However, if the type passed in by the newinstance method is not the specified type at runtime, it will cause an exception during running, which is difficult to predict in advance.

Next, let's take a look at how to call the object method: You can call the getmember method or the getmembers method to obtain the methodinfo object or array, and then call the invoke method of the methodinfo object. Let's look at the following code.

Code

  1 // Example usage:
 2 Dispatcher.InvokeMethod( AnObject, "MyHelperFunc" );
 3 
 4 // Dispatcher Invoke Method:
 5 public void InvokeMethod ( object o, string name )
 6 {
 7   // Find the member functions with that name.
 8   MemberInfo[] myMembers = o.GetType( ).GetMember( name );
 9   foreach( MethodInfo m in myMembers )
10   {
11     // Make sure the parameter list matches:
12     if ( m.GetParameters( ).Length == 0 )
13       // Invoke:
14      m.Invoke( o, null );
15   }
16 }

The above code is just a simple example. It only calls the non-argument method of the object. To create a reusable library, you also need to add a check for the parameter type.

Finally, let's take a look at how to access the properties of an object: You can call the getfield method or the getfields method to obtain the filedinfo object or array; you can call the getproperty method or the getproperties method to obtain the propertyinfo object or array; call the getvalue method to obtain the value of the specified attribute. Let's look at the following code.

Code

  1 // Example usage:
 2 object field = Dispatcher.RetrieveField ( AnObject, "MyField" );
 3 
 4 // elsewhere in the dispatcher class:
 5 public object RetrieveField ( object o, string name )
 6 {
 7   // Find the field.
 8   FieldInfo myField = o.GetType( ).GetField( name );
 9   if ( myField != null )
10     return myField.GetValue( o );
11   else
12     return null;
13 }

Reflection brings about a weak type problem. In this way, we can find other solutions to dynamically create objects. We can use interfaces to specify the object type at runtime.

Reflection should be used only when the call target cannot be clearly expressed using interfaces.

To sum up, when we can use interfaces to describe the methods or attributes we expect to call, we will get a clearer and more Maintainability System. Reflection is a powerful late binding mechanism, but in some cases, we can use interfaces, delegation, or factory models to obtain more maintainability systems.