Reflection [reprinted]

Reflection
Mike Repass
Http://msdn.microsoft.com/msdnmag/issues/07/06/CLRInsideOut/default.aspx? Loc = en

Is the clear componentization goal lost by sharing too many types of information between libraries? You may need efficient and strongly typed data storage, but if you need to update your database architecture after every development of the object model, it will be very costly, so are you more willing to deduce its type architecture during runtime? Do you need to deliver components that can accept any user object and process them in an intelligent way? Do you want library callers to show you their types programmatically?

If you find that you are struggling to maintain a strongly typed data structure while looking to maximize runtime flexibility, you may be willing to consider reflection and how it improves your software. In this column, I will discuss Microsoft^{The System. Reflection namespace in. NET Framework and how it helps your development experience. I will start with some simple examples and finally explain how to deal with serialization in the real world. In this process, I will show how reflection and CodeDom work together to effectively process runtime data.}

Before in-depth exploration of system. reflection, I would like to discuss general reflection programming first. First, reflection can be defined as any function provided by a programming system. This function allows programmers to check and manipulate code entities without having to know their identity or formal structure in advance. This part contains a lot of content. I will describe it one by one.

First, what does reflection provide? What can you do with it? I tend to divide a typical reflection-centered task into two types: Check and operation. Check the objects and types to be analyzed to collect structured information about their definitions and behaviors. Except for some basic provisions, this is usually done without prior knowledge of them. (For example, in. NET Framework, everything inherits from system. object, and an object type reference is usually the general starting point of reflection .)

The operation dynamically calls the code by checking the collected information, creates a new instance of the discovered type, or even easily restructures the type and object dynamically. One important point to be pointed out is that for most systems, the operation types and objects during runtime will cause performance degradation compared to static operations in source code. Because of the dynamic characteristics of reflection, this is a necessary trade-off, but there are a lot of tips and best practices to optimize the performance of reflection (more in-depth information on optimizing the use of reflection, see msdn.microsoft.com/msdnmag/issues/05/07/reflection ).

So what is the goal of reflection? What are the actual checks and operations of programmers? In my definition of reflection, I used the new term "code entity" to emphasize the fact that, from the programmer's perspective, reflection technology sometimes blur the boundaries between traditional objects and types. For example, a typical reflection-centric task may be:

1. Starts from the handle of object O, and obtains the handle of its related definition (type T) Using Reflection.
2. Check type T to obtain the handle of its method M.
3. Call method M of another object o' (also type T.

Please note that I am moving from an instance to its underlying type, from this type to a method, then, use the handle of this method to call it on another instance-obviously this is not implemented by using the traditional C # Programming Technology in the source code. After discussing system. Reflection of. NET Framework, I will explain this situation through a specific example.

Some programming languages can provide reflection through syntax, while other platforms and frameworks (such as. NET Framework) use it as the system library. Regardless of the method in which reflection is provided, the possibility of using reflection technology in a given situation is quite complex. The ability of a programming system to provide reflection depends on a number of factors: Do programmers use the functions of programming languages to express their concepts? Does the compiler embed enough structured information (metadata) in the output to facilitate future interpretation? Is there a runtime subsystem or host interpreter to digest the metadata? Does the platform library display this interpretation result in a useful way for programmers?

If you think of a complex, object-oriented system, but the code shows a simple, C-style function, and there is no formal data structure, obviously, your program cannot dynamically infer that the pointer of a variable V1 points to an object instance of a certain type T. After all, type T is a concept in your mind and never appears explicitly in your programming statements. However, if you use a more flexible object-oriented language (such as C #) to express the abstract structure of a program and directly introduce the concept of type T, then the compiler will convert your idea into a form that can be understood by appropriate logic in the future, just like the Common Language Runtime (CLR) or a dynamic language interpreter provides the same.

Is reflection completely dynamic and runtime technology? In short, this is not the case. Reflection is often available and useful to developers throughout the development and execution cycle. Some programming languages are implemented through independent compilers, which directly convert advanced code into commands that can be recognized by machines. The output file only contains compiled input, and does not support the logic used to accept opaque objects and dynamically analyze their definitions at runtime. This is exactly the case for many traditional C compilers. Because almost no logic is supported in the target executable file, you cannot perform much dynamic reflection. However, the compiler will provide static reflection from time to time-for example, the commonly used typeof operator allows programmers to check type identifiers during compilation.

Another completely different scenario is that an interpreted programming language is always executed through the main process (the scripting language generally belongs to this type ). Because the complete definition of the program is available (as the input source code) and combined with the complete language implementation (as the interpreter itself ), therefore, all technologies required to support self-analysis are in place. This dynamic language frequently provides comprehensive reflection capabilities, as well as a rich set of tools for dynamic analysis and operation procedures.

. NET Framework CLR and its bearer language such as C # are intermediate forms. The compiler is used to convert source code into IL and metadata. Although the latter is lower-level or less "logical" than the source code, it still retains a lot of abstract structure and type information. Once the CLR starts and carries this program, the System. Reflection library of the base class library (BCL) can use this information and return information about the object type, type member, and member signature. In addition, it supports calling, including later binding calls.

Reflection in. NET

To use Reflection for programming with. NET Framework, you can use the System. Reflection namespace. This namespace provides classes that encapsulate many runtime concepts, such as assemblies, modules, types, methods, constructors, fields, and attributes. The table in Figure 1 shows how the classes in System. Reflection correspond to the corresponding items when the concept is running.

Although important, System. Reflection. Assembly and System. Reflection. Module are mainly used to locate new code and load it to runtime. In this column, I will not discuss these parts for the moment, and assume that all the relevant code has been loaded.

To check and operate on loaded code, the typical mode is System. Type. Generally, you get a System. Type instance of the runtime Type of interest (through Object. GetType ). Then you can use various methods of System. Type to explore the definition of the Type in System. Reflection and obtain instances of other classes. For example, if you are interested in a specific method and want to obtain a System. Reflection. MethodInfo instance for this method (possibly through Type. GetMethod ). Similarly, if you are interested in a field and want to obtain a System. Reflection. FieldInfo instance for this field (possibly through Type. GetField ).

Once you get all the necessary reflection instance objects, you can continue to follow the inspection or operation steps as needed. During the check, you use various descriptive attributes in the reflection class to obtain the information you need (is this a common type? Is this an instance method ?). You can call and execute Methods dynamically, create new objects by calling constructor, and so on.

Check type and members

Let's jump to some code and explore how to use basic reflection for inspection. I will focus on Type Analysis. Starting from an object, I will retrieve its type and then examine several interesting members (see figure 2 ).

The first thing to note is that in the class definition, the length of the method is much larger than I expected. Where do these additional methods come from? Anyone proficient in the. NET Framework Object hierarchy will recognize these methods inherited from the generic base class Object itself. (In fact, I first used Object. GetType to retrieve its type .) In addition, you can see the getter function of the attribute. What should I do if you only need functions explicitly defined by MyClass? In other words, how do you hide inherited functions? Or do you only need to explicitly define Instance functions?

Watch MSDN online^{You will find that you are willing to use the second GetMethods overload method, which accepts the BindingFlags parameter. By combining different values from the BindingFlags enumeration, you can let the function only return the required method subset. Replace the GetMethods call:}

GetMethods(BindingFlags.Instance | BindingFlags.DeclaredOnly |            BindingFlags.Public)

The result is that you get the following output (note that there are no static helper functions and functions inherited from System. Object ).

Reflection Demo Example 1Type Name: MyClassMethod Name: MyMethod1Method Name: MyMethod2Method Name: get_MyPropertyProperty Name: MyProperty

What if you know the type name (fully qualified) and member in advance? How do you convert an enumeration type to a retrieval type? The example in Figure 3 shows how to use the string text describing the Type information through Object. GetType and Type. GetMethod to retrieve the corresponding items of the actual code. With the code in the first two examples, you have the basic components that can implement the primitive browser. You can find a runtime object by name, and then enumerate its various related attributes.

Dynamic call code

So far, I have obtained the handle (such as type and method) of runtime objects for descriptive purposes only, such as output their names. But how can we do more? How do I actually call a method? Figure 4 shows how to obtain the MethodInfo of a type of member and then use MethodInfo. Invoke to dynamically call this method.

The main points of this example are: first, retrieve a System. Type instance from a MyClass, mc1 instance, and then retrieve a MethodInfo instance from this Type. Finally, when MethodInfo is called, it is passed as the first parameter of the call and bound to another MyClass (mc2) instance.

As mentioned above, for the difference between the type and object usage that you expect to see in the source code, this example blur the difference. Logically, you retrieve the handle of a method and call this method, just as it belongs to a different object. This may be easy for programmers who are familiar with functional programming languages, but for programmers who are only familiar with C #, separating object implementation and Object Instantiation may not be so intuitive.

Combined

Now I have discussed the basic principles of checking and calling. Next I will combine them with specific examples. Imagine that you want to deliver a library with a static helper function that must process objects. However, you have no idea about the types of these objects during design! This depends on the instruction of the function caller and how he wants to extract meaningful information from these objects. The function accepts an object set and a string descriptor of a method. It then traverses the set, calls the methods of each object, and aggregates the returned values with some functions (see figure 5 ).

In this example, I want to declare some constraints. First, the string parameter description method (which must be implemented by the underlying type of each object) does not accept any parameters and returns an integer. The Code traverses the object set, calls the specified method, and gradually calculates the average value of all values. Finally, because this is not a production code, I don't have to worry about parameter verification or integer overflow during summation.

When browsing the sample code, we can see that the protocol between the main function and the static helper ComputeAverage does not depend on any type information except the general base class of the object itself. In other words, you can completely change the type and structure of the object being transferred, but as long as you can always use a string to describe a method and return an integer, ComputeAverage can work normally!

A key issue to be noted is related to MethodInfo (general reflection) hidden in the last example. Note: In the foreach loop of ComputeAverage, the Code captures only one MethodInfo from the first object in the set, and then binds it to call all subsequent objects. As shown in the code, it runs well-this is a simple example of MethodInfo caching. However, there is a fundamental limitation here. A MethodInfo instance can only be called by instances of the same level of objects it retrieves. This operation can be performed only when instances of IntReturner and SonOfIntReturner (inherited from IntReturner) are passed in.

The sample code already contains the class named EnemyOfIntReturner, which implements the same basic protocol as the other two classes, but does not share any common sharing types. In other words, this interface is logically equivalent, but does not overlap at the type level. To explore the use of MethodInfo in this case, try to add other objects to the set, get an instance through "new EnemyOfIntReturner (10)", and run the example again. You may encounter an exception stating that MethodInfo cannot be used to call the specified object because it is completely irrelevant to the original type when obtaining MethodInfo (even if the method name is equivalent to the basic protocol ). To make your code reach the production level, you must be prepared for this situation.

One possible solution is to analyze the types of all input objects by yourself and retain the explanations of the shared type level (if any. If the type of the next object is different from that of any known type, you need to obtain and store a new MethodInfo. Another solution is to capture TargetException and obtain a new MethodInfo instance. The two solutions mentioned here have their own advantages and disadvantages. Joel Pobar wrote an excellent article about the MethodInfo buffer and the reflection performance I strongly recommend for the 2007 issue.

If you want to add reflection to an application or framework in this example, you can add more flexibility for future customization or scalability. It is undeniable that reflection may be cumbersome compared to the equivalent logic in the local programming language. If you feel that for you or your customers, adding reflection-based post-binding to code is too troublesome (after all, they need to describe their types and code in some way in your framework ), you may only need moderate flexibility to strike a balance.

Efficient serialization type Processing

Now we have explained the basic principles of. NET reflection through several examples. Let's take a look at the situation in the real world. If your software interacts with other systems through Web services or remote technology outside of other processes, you may have encountered serialization problems. Serialization is essentially to convert an active, memory-occupied object into a data format suitable for online transmission or disk storage.

.. NET Framework. XML. the serialization namespace provides a powerful serialization engine with xmlserializer. It can use any hosted object and convert it to XML (XML data can also be converted back to typed object instances in the future, this process is called deserialization ). The xmlserializer class is a powerful enterprise-ready software snippet. If you are faced with serialization problems in your project, it will be your first choice. But for the purpose of teaching, we will discuss how to implement serialization (or other similar runtime type processing instances ).

Imagine: You are delivering a framework that uses any user type object instance and converts it to a certain smart data format. For example, assume that there is a resident memory object with the address type as follows:

(pseudocode)class Address{    AddressID id;    String Street, City;    StateType State;    ZipCodeType ZipCode;}

How to generate appropriate data representation for future use? A simple text Presentation may solve this problem:

Address: 123    Street: 1 Microsoft Way    City: Redmond    State: WA    Zip: 98052

If you fully understand the formal data types to be converted (for example, when writing your own code) in advance, the process becomes very simple:

foreach(Address a in AddressList){    Console.WriteLine(“Address:{0}”, a.ID);    Console.WriteLine(“/tStreet:{0}”, a.Street);    ... // and so on}

However, if you do not know the data type that you will encounter during running, the situation will become very interesting. How do you compile general framework code like this?

MyFramework.TranslateObject(object input, MyOutputWriter output)

First, you need to determine which types of members are useful for serialization. Possible scenarios include capturing only specific types of members, such as primitive system types, or providing a mechanism for Type authors to explain which members need to be serialized, for example, use custom attributes as tags on type members ). You can only capture members of specific types, such as primitive system types, or the type Author can explain which members need to be serialized (the possible method is to use custom attributes as tags on the Type members ).

Once you have logged the members of the data structure to be converted, you need to write the logic to enumerate and retrieve them from the input objects. Reflection carries on a heavy task here, allowing you to query both the data structure and data values.

For simplicity, we design a lightweight conversion engine, get an object, get all its public attribute values, convert them to strings by directly calling tostring, and then serialize these values. For a given object named "input", the algorithm is roughly as follows:

1. Call input. GetType to retrieve the System. Type instance. This instance describes the underlying structure of input.
2. Use Type. GetProperties and the appropriate BindingFlags parameters to retrieve the public attributes as PropertyInfo instances.
3. Use PropertyInfo. Name and PropertyInfo. GetValue to retrieve attributes as key-value pairs.
4. Call Object. ToString on each value to convert it (in the basic mode) to the string format.
5. Pack the object type name, attribute name, and string value set into the correct serialization format.

This algorithm obviously simplifies things and also captures the essentials of getting the runtime data structure and converting it into self-descriptive data. But here is a problem: performance. As mentioned earlier, reflection costs a lot for type processing and value retrieval. In this example, I perform a complete Type Analysis in each provided instance.

If you can capture or retain your understanding of the type structure in some way, you can easily retrieve it in the future and effectively process new instances of this type; in other words, step #3 in the example Algorithm? The good news is that using the features in the. NET Framework is completely possible. Once you understand the data structure of the type, you can use CodeDom to dynamically generate code bound to the data structure. You can generate a helper Assembly that contains the helper class and a method that references the input type and directly accesses its attributes (similar to any other attribute in the managed code ), therefore, type checks only affect the performance once.

Now I will revise this algorithm. New Type:

1. Obtain the System. Type instance corresponding to this Type.
2. Use various System. Type accessors to retrieve architectures (or at least retrieve a subset of architectures useful for serialization), such as attribute names and field names.
3. Use schema information to generate a helper assembly (through CodeDom) that is linked to the new type and processes instances effectively.
4. Use code in the Helper Program to extract instance data.
5. Serialize data as needed.

For all input data of the given type, you can jump forward to step #4. This can greatly improve the performance compared to explicitly checking each instance.

I developed a basic serialization library named SimpleSerialization, which implements this Algorithm Using Reflection and CodeDom (which can be downloaded in this column. The main component is a class named SimpleSerializer, which is constructed by a System. Type instance. In the constructor, the new SimpleSerializer instance analyzes the given type and uses the helper class to generate a temporary assembly. The helper class is closely bound to the given data type, and the processing method for the instance is as if you have fully understood the type before writing the code.

The SimpleSerializer class has the following layout:

class SimpleSerializer{    public class SimpleSerializer(Type dataType);    public void Serialize(object input, SimpleDataWriter writer);}

Simple and amazing! The constructor undertakes the heaviest task: it uses reflection to analyze the type structure and uses CodeDom to generate a helper assembly. The SimpleDataWriter class is only a data receiver used to clarify common serialization modes.

To serialize a simple Address class instance, use the following pseudo code to complete the task:

SimpleSerializer mySerializer = new SimpleSerializer(typeof(Address));SimpleDataWriter writer = new SimpleDataWriter();mySerializer.Serialize(addressInstance, writer);

End

We strongly recommend that you try the sample code yourself, especially the SimpleSerialization library. I added comments to some interesting parts of SimpleSerializer, hoping to help. Of course, if you need to strictly serialize the product code, you must rely on the technology provided in. NET Framework (such as XmlSerializer ). However, if you find that you need to use any type of data at runtime and can efficiently process them, I hope you will use my SimpleSerialization library as your own solution.

We are grateful for the guidance and feedback from CLR developers Weitao Su (reflection) and Pete Sheill (CodeDom.

 

Download Demo