Line 1 shows the subdirectory where the class is stored. Line 3 defines class Simulator as final. By making the class Simulator final, it prevents cloneability to be added to this class by the mechanism of inheritance. The Java environment allows object creation through cloning. As Simulator is a subclass of the superclass Object, the clone method defined in Object normally is inherited and becomes part of the behavior of Simulator. Or making class Simulator final prohibits the inheritance mechanism from occurring. Thus, objects of class Simulator cannot be cloned. This is another step to make sure that class Simulator will not be able to create more than one instance of it. Line 4 assigns attribute instance to null. Line 6 defines a private constructor to prevent the compiler from inserting a default constructor. Lines 7 through 10 define the method getlnstanceQ that delivers the only instance of the class Simulator. In the case where no instance of Simulator is yet created, then line 8 will create it. In the case where the unique instance is already created, line 9 simply returns this instance. This way of creating an instance of an object only when it is needed is referred to as lazy initialization.

4. STRUCTURAL PATTERNS 4.1 The adaptor pattern

The purpose of the adaptor pattern is to convert the interface of a class into another interface clients expect [GHJ95]. The adaptor makes it possible for two classes to work together when they cannot communicate with each other because they implement different interfaces.

To better understand the need for the adaptor pattern, let us take a closer look at two different water-balance models described by [PSh04]. The models are Ritchie's water-balance model [Rit98] and the ISM (Irrigation Scheduling Model) developed by [GSR00].

Ritchie's model uses the United States Soil Conservation Service (SCS) method to determine runoff and in turn, calculate the amount of water that enters the soil surface. This method in Ritchie's model is referred to as calculatelnfiltration. The ISM model describes the amount of water entering the soil as effective rainfall and uses the SCS method to determine this amount. In the ISM model, the same method is referred to as calculateEffectiveRainfallSCS. Both models refer to the same process using different names.

Let us suppose that each of these models is developed as a component that can be plugged into some decision support system used for crop yield simulation. Ritchie's component will provide the amount of water that enters the soil surface by responding to the message calculatelnfiltration, whereas the ISM component will provide the same result by responding to the message calculateEffectiveRainfallSCS. Let us suppose that initially the decision support system uses Ritchie's component. The object that needs to know the amount of water entering the soil sends the appropriate message to Ritchie's component. In the case that there is a need to replace Ritchie's component with the ISM component, there is a problem as Ritchie's and ISM components implement different interfaces. An object that can communicate with Ritchie's component by sending the message calculatelnfiltration cannot communicate with the ISM component as the latter does not recognize this message. The sender of the message calculatelnfiltration ignores the fact that the ISM component does not understand this message and that the understood message is calculateEffectiveRainfallSCS. Although the developers have used good design techniques to develop these two models as components, the reusability of components is impacted by the different naming conventions used by different authors.

This problem can be solved using the adaptor pattern as shown in Figure 7-9.

DecisionSupoit System



0 0

Post a comment