Reflection

Complex and dynamic systems allow for the fact that the environment in which they run may change constantly. In an object-oriented environment, classes are loaded dynamically, binding is done dynamically, and object instances are created dynamically when they are needed. Therefore, there is a need to collect information about the object that is dynamically created. Reflection provides the answer to the above problem. Both Java and .NET technologies provide ample support for reflection. The .NET framework uses reflection to inspect the content of assemblies [Pro02] and Java uses it to collect internal information about classes or components (http://iavasoft.com). As Java is the implementation language for our application, only details for Java's Reflection API are provided.

In Java, the Reflection API has a two fold purpose. First, it provides a mechanism to fetch data about a class/component and second, a means for extracting objects composing the class/component. Using reflection, it is possible to obtain internal information about the class/component such as its superclass, the interfaces the class implements, the methods, their signatures, and the returning object. The behavior for fetching data about a class is provided in a class referred to as Class. Class is the universal type for the meta information that describes objects within the Java system. Class loaders in the Java system return objects of type Class.

Figure 9-2 shows the Java implementation of the combination of patterns Strategy and AbstractFactory using the behavior of class Class as defined in Java's Reflection API. In this figure, line 3 defines the method newInstance(className) that creates an object of type className. Lines 5 through 10 load the class className using the current class loader, and lines 11 through 24 create an instance of class className. The name of the class/component to be used in the system can be provided by a configuration file as shown in Figure 9-3. In this case, the simulation system will use classes Plant, Soil, and WeatherDataFromFile. Thus, the decision about the type of objects to be created can be made during execution by a component-controller, not in the source code. In order to plugin another class, for example, WeatherDataFromDatabase, only the content of the configuration file needs to be updated with the appropriate class name. Thus, no changes to the code are required. The component-controller, in our case SimulationController, instantiates the right components at run time. Using the plug and play architecture, the user has the choice to activate different classes that provide similar behavior but implement the same interface.

1 public class ObjectFactory {

0 0

Post a comment