Design Patterns: Policy mode and Adapter mode _ Adapter Mode

The policy pattern is used to abstract different ways of dealing with the same object, to abstract the same processing (internal state) into a class, and to select the class by policy to produce the corresponding policy to process the input object.

To put it another way, the strategy model needs to be used in conjunction with a simple factory model, an evolutionary version of a simple factory class. It can be said that the strategy model is a necessary to implement a simple factory model. Just as the different algorithms of the calculator are encapsulated into objects directly, this is actually the policy pattern, and then the different policy objects are returned by the judgment in the simple factory class subtraction. (P.S. Factory approach is to encapsulate the different factories that return subtraction into objects.) ）

However, the great thing about the strategy model is that it better encapsulates internal processing and better decoupling from client code. The key is to create a policy selection class. First look at the general Picture:

The policy selection class is the context.

Let's sample the simple factory method for the code, and say how better to decouple from the client:

First, the abstract class (or interface) of the policy class is defined as usual, and the different policy implementation classes are the implementation classes of the interfaces and operators of the operator class:

interface operation{  
    int calculateresult (int a, int b);  
}  

Class Operationadd implements operation{public  
   int Calculateresult (int a, int b) {return  
      a+b;  
   }  
}  

Next, define a context class:

<pre name= "code" class= "java" ><pre name= "code" class= "Java" >public class context{public  
   static int GetResult (Operation ins, int a, int b) {return  
      ins.calculateresult (a,b);  
   }  
  

In fact, this is the mode of the strategy, it's quite a drag.

Because the client still needs to know what class of operations, then according to user input, generate the corresponding operation class object, and then call the context. In this way, the client code contains redundant code. So, we can combine the factory code, all the judgments, calculations are included in the context to do:

public class context{Public  
   int GetResult (String s, int a, int b) {
     switch (s) {case  
       ' Add ': Return CONTEXT.GETR Esult (New Operationadd, A, b);  
       Case "Minus": Return Context.getresult (New, Operationminus, A, b);  
       ......  
      }  
  }
   private static int GetResult (Operation ins, int a, int b) {return  
      ins.calculateresult (a,b);  
   }  
  

In this way, our client code can be changed to:

public class customer{public
  static void Main (Strings args[]) {The context
    ins = new context ();
    int result Ins.getresult ("add", 1,2);
  }

Compare the client code for the previous simple factory pattern:

public static void Main (string[] args) {  
  Operation op = simplefactory.getoperation ("+");  
  int result = Op.calculateresult (1,1);  
}  

We can see that now even the abstract class or interface operation do not need to let the client know. The decoupling of such a son is even more thorough.

and adapter mode, in fact, I prefer to call it translation mode. It allows the interface to be different (the method name is different) but the function is similar two classes, through a translation class, enables can through one class's interface (language) to direct another class to do the function similar thing. The appearance of the adapter pattern is motivated by two classes that implement different interfaces, but with similar functions, they can be invoked with the same interface to achieve similar functions. This pattern is very useful in real-world software design, in other people's library functions have been written, you can only invoke the case, you find that from two different libraries have two classes, they actually some methods implement similar functions, such as all realize Fourier transform, but a class is discrete signal class, Its Fourier transform function is: ftrans_func (wave input), and the other is a continuous signal class, its Fourier transform function is: Ftrans (wave input). I want to call these two functions with a unified interface, assuming I want to invoke the function of the continuous signal using the interface of the discrete signal, and the discrete signal class has a parent class interface that is a signal class, defined as:

Interface signal{
  wave ftrans_func (wave input);
}

So, we can create an adapter class that is the implementation class for the signal class:

public class Continuedsignaladapter implements signal{
  private continuedsignal = new continuedsignal;//used to invoke ftrans< C3/>public Wave Ftrans_func (Wave input) {return
    Continuedsignal.ftrans (input);
  }

In this way, you can implement a similar method of calling two classes with the same interface.

I have also written a blog about the adapter, you can refer to: http://blog.csdn.net/Firehotest/article/details/51993922

A picture from the big talk design pattern also explains the adapter pattern well.