Info

^calculai elnfiltrationQ

Figure 7-9. Class diagram for the adaptor pattern.

Figure 7-9. Class diagram for the adaptor pattern.

The decision support system uses Ritchie's model. This is shown in Figure 7-9 by the association uses between the DecisionSupportSystem class and the InterfaceRitchie interface. InterfaceRitchie defines a method referred to as calculatelnfiltration. The Adaptor class implements InterfaceRitchie; therefore, it should provide an implementation for the method calculatelnfiltration. Class Adaptor has an association with InterfaceISM, which allows Adaptor to access data and behavior from InterfaceISM. The body of the method calculatelnfiltration defined in the Adaptor class does not do calculations, but it simply delegates execution to the method calculateEffectiveRainfallSCS defined in InterfaceISM.

As the DecisionSupportSystem class knows how to call the method calculatelnfiltration from InterfaceRitchie, it therefore knows how to call the same method from class Adaptor because Adaptor implements InterfaceRitchie. Therefore, the DecisionSupportSystem class can call a method defined in InterfaceISM even when it cannot communicate directly with this interface. The Adaptor class makes possible the communication between two classes when there is no association between them, as shown in Figure 7-10.

InterfaceRitchie

♦catculateinfittrationO

DecisionSu portSyst em

"E

InterfaceISM

InterfaceISM

Figure 7-10. An adaptor allows communication between classes that do not implement the same interface.

Adaptor

^calcuiateEffectiveRainfailSCSO

1 ♦calculatelnfiltrationO

Figure 7-10. An adaptor allows communication between classes that do not implement the same interface.

Figures 7-11, 7-12, and 7-13 are examples of a simple implementation in Java of classes that are involved in the adaptor pattern presented in Figure 79. Figure 7-11 shows a simplified definition of InterfaceISM that defines the public interface for all the classes implementing this interface. This interface defines a method referred to as calculateEffectiveRainfallSCS that will calculate the amount of water that enters the soil surface. Interfaces only define the name of the methods and their signature; they do not provide the logic of the implementation.

1 package AdaptorPattern;

2 public interface InterfaceISM {

3 public double calculateEffectiveRainfallSCSQ;

Figure 7-12 shows a simplified definition of the interface InterfaceRitchie that defines the public interface of all the classes implementing this interface. This interface also, defines a method referred to as calculatelnflltration that calculates the amount of water entering the soil surface according to Ritchie's model. Figure 7-13 shows the definition of class Adaptor. Line 3 shows that class Adaptor implements InterfaceRitchie; therefore, Adaptor should provide an implementation of the method calculatelnflltration defined by the interface. Line 5 shows that Adaptor has an attribute of type InterfaceISM that allows class Adaptor to access data and behavior from any class implementing InterfaceISM. Lines 7 to 10 show the definition of method calculatelnflltration. The result of this method is of type double. Line 9

Figure 7-11. Definition of InterfaceISM.

shows that the execution is delegated to object ism that points to an object of type InterfacelSM. The result of the method calculatelnfiltration is obtained by executing the method calculateEffectiveRainfallSCS defined in InterfacelSM. In this way, object DecisionSupportSystem can send the message calculatelnfiltration to object InterfacelSM without knowing about the latter.

1 package AdaptorPattern;

2 public interface InterfaceRitchie {

3 public double calculatelnfiltrationQ;

Figure 7-12. Definition of InterfaceRitchie.

1 package AdaptorPattern;

2 public class Adaptor implements InterfaceRitchie {

3 private InterfacelSM ism;

4 public double calculateInfiltration() {

5 return ism.calculateEffectiveRainfallSCS();

Figure 7-13. Definition of class Adaptor.

4.2 The proxy pattern

The intent for this pattern is to add a level of indirection with a surrogate object that provides the same services as the real object. The surrogate object is responsible for controlling access to the real object [Lar02].

This pattern is almost never used by itself; usually it is used by other patterns. The proxy pattern plays an important role in middleware software such as Java's RMI and CORBA. These technologies are presented later in this book.

A proxy object is designed to receive calls for another real object, the object that provides the required service. Therefore, the proxy and the real object should provide the same services. The proxy object does not provide any implementation for the behavior defined in the real object; it only delegates the call to this one. Thus, the proxy object makes the location of the real object irrelevant to its clients. A proxy object is located near the client that needs the services. Clients that use the behavior of the real object are not aware of the location of this object; the proxy makes it look as clients are communicating with the real object. Figure 7-14 shows class diagrams for the proxy object.

Figure 7-14. Class diagram for the proxy object.

As shown in this figure, the real object and the proxy object may implement the same interface or they may have a common superclass. In the case they implement the same interface, the real object and the proxy object provide a polymorphic implementation of the behavior defined in the interface. While the real object provides an implementation for the behavior defined in the interface, the proxy's behavior is to delegate the call to the real object.

How do the proxy and the real object communicate with each other? Figure 7-15 shows the communication between the proxy and the real object.

Figure 7-15. Communication between the proxy and the real object.

Figure 7-15. Communication between the proxy and the real object.

A client that needs to use the services provided by the real object sends a message to the proxy. As the proxy object implements the same interface as the real object, it recognizes the method call and it delegates it to the real object. The real object executes the call and returns the results to the proxy object that communicates them to the client. The client is unaware of the fact that the service requested is provided through the proxy. More details about the implementation of the proxy object will be provided later in this book in Chapter 11.

0 0

Post a comment