Figure 7-19. Communication with GUI classes goes through the Simulator.

5. BEHAVIORAL PATTERNS 5,1 The state pattern

The purpose of the state pattern is to allow an object to alter its behavior when its internal state changes [GHJ95]. Using this pattern makes it easier to model some complicated scenarios often present in biological simulation models.

Let us consider the example of the lifecycle of an insect. At the beginning, an insect exists in the form of eggs. Later on, as the incubation period ends, eggs are transformed into larvae and finally a larva is transformed into an adult insect. During its different development stages, an insect has different characteristics or properties. An egg has a different behavior from a larva and a larva behaves differently from an adult insect. How can an entity be modeled as an object when it has different characteristics and behavior during different phases of its life? The state pattern can be used to solve this type of problems. Figure 7-20 presents a class diagram for the state pattern.

Figure 7-20. The UML diagram for the state pattern.

According to Figure 7-20, class Insect has an association with another class named DevelopmentStage. Class DevelopmentStage is subclassed by three other classes Egg, Larvae, and Adultlnsect, representing the three different development stages of an insect. The role of class DevelopmentStage is to define an interface common to all subclasses and can be modeled as an abstract class. Class Insect defines the common characteristics of the insect regardless of its current development stage such as name of the specie, etc. Because of the relationship with DevelopmentStage, class Insect has an attribute of type DevelopmentStage referred to as currentStage that allows access to data and behavior of each of the subclasses. Therefore, class Insect can delegate all received messages to the particular subclass that defines the current development stage. It is important to note that attribute currentStage can hold only one value at a time, representing the fact that an insect can be at one development stage at the time. If we need to know the current development stage of the insect, then the message getDevelopmentStage should be sent to object Insect and the result is the name of the class referenced by attribute currentStage. Each of the subclasses will define data and behavior necessary to describe the particular development stage of the insect.

Class DevelopmentStage has a method referred to as nextStage. The purpose of this method is to determine the insect's next stage. As class DevelopmentStage is an abstract class, the method nextStage will have no implementation. This method is inherited by all the subclasses (Egg, Larvae, and Adultlnsect) and each of the subclasses will provide a specific implementation of this method. As an example, the method nextStage applied to an object of class Egg will return an instance of type Larvae.

When the message nextStage is send to an object, for example, to object Larvae, besides delivering an object representing the next development stage, the object should destroy itself. Thus, the creation of an object representing the next development stage is accompanied with the destruction of the previous stage; a new object of type Adultlnsect is created and the current object of type Larvae is destroyed. Every time that a change happens, the name of the newly created object is stored in the attribute currentStage of class Insect.

5.2 The strategy pattern

The intent for this pattern is to define a family of algorithms, encapsulate each one, and make them interchangeable [GHJ95]. Therefore algorithms can vary independently from the clients that use them.

In order to better understand the context in which the strategy pattern operates, let us consider the example of obtaining weather data for a crop simulation system. We have previously mentioned that these data can be obtained using different sources such as using a text file where the data are saved, reading them from a database system, or using an on-line system of weather stations. A well-thought-out system should provide behavior for using several sources of weather data or, in other words, several strategies should be available to users. In a system developed in a traditional programming language such as FORTRAN, the ability to choose between several options would require the use of complex if-then-else statements.

Furthermore, the use of an if-then-else statement will allow for using only known scenarios. In the case where a new way of obtaining weather data is made available, changes to the code are required. Therefore, traditional programming languages offer rather limited and rigid solutions to this problem.

The object-oriented paradigm solves this problem by offering a flexible and better solution. The behavior for using different sources of weather data will be implemented as different classes; each class should provide weather data from a particular source. Then, the question is, how do we choose the right class between several potential ones? The strategy pattern can be used to solve this type of problems. Figure 7-21 shows classes that are involved in the strategy pattern.

The WeatherDataManager class provides the behavior for managing the weather data (i.e., provides the capability of using different sources of weather data.) The WeatherDataProvider is an interface that represents the common behavior all classes that provide a particular implementation of this interface should implement. Each class is designed to provide data from a particular source. The WeatherDataManager has a unidirectional association with WeatherDataProvider. The multiplicity of this association allows one manager to use one or zero weather data provider. Classes WeatherDataFromFile, WeatherDataFromStation and WeatherDataFrom Database provide behavior for extracting data from a particular source of data. These classes implement the same interface, the WeatherDataProvider interface; therefore, any one of them can be used to provide the weather data requested by the weather data manager.

0 0

Post a comment