There are six principles and twenty-three design patterns in design patterns. The six principles are single responsibility principle, open and close principle, Richter substitution principle, dependence inversion principle, interface isolation principle, Demeter principle. Twenty-three Design Mode: Singleton pattern, Builder Models, prototype pattern, factory method, abstract factory pattern, strategy pattern, state model, the chain of responsibility pattern, the interpreter, command mode, the observer pattern, memos, iterators, template method, the visitor pattern, mediation patterns, the proxy pattern, combination mode, the adapter pattern, decorative pattern, the flyweight pattern, appearance, bridge .

Strategy mode in our development is also more common, for example, in Android often use MVP and strategy mode is very similar, Java development we will often set a class in the past and so on, these are based on the strategy mode. Those of you who have used the factory pattern may find that the factory pattern is very similar to the policy pattern, similar in usage and so on, but they are not the same. The factory pattern is mainly for creating objects, while the policy pattern is mainly for using objects.

define

The policy pattern defines a list of algorithms, encapsulates each one, and allows the algorithm to change independently of the customers that use it.

Objects have a behavior, but different scenarios have different algorithms for implementing that behavior.

Usage scenarios

  • Multiple treatments for the same type of problem
  • You need to safely encapsulate multiple operations of the same type, hiding the implementation from the customer.
  • When there are multiple subclasses of the same abstract class and you need to use if-else or switch-case to select the concrete subclass.

The advantages and disadvantages

advantages

  • The structure is clear and simple to use
  • The coupling degree is relatively low, and the expansion is convenient
  • Operation encapsulation is more complete and data is more secure

disadvantages

  • As the policy increases, the number of classes becomes larger and more prone to class explosions
  • The consumer must know all the policy classes and figure out which policy to use

UML diagrams

  • The Context class is used to manipulate the Context of the policy
  • Strategy Class policy abstraction
  • ConcreteStrategyA, ConcreteStrategyB concrete implementation class

Code implementation

  • It is not implemented in a policy mode
   /** * Instead of using policy mode to use methods, call different logic based on type *@paramType type * /
    public void test(String type){
        if ("A".equals(type)){
            System.out.println("ConcreteStrategyA:method");
        }else if ("B".equals(type)){
            System.out.println("ConcreteStrategyB:method");
        }else {
            System.out.println("test"); }}// The usage mode
    public static void main(String[] args) {
        // Do not use the policy pattern usage method
        Context test =new Context();
        test.test("A");
    }
Copy the code

When the policy mode is not used, we use if else or Switch case to judge the business, which can cause high coupling and is inconvenient for subsequent maintenance. Using policy mode, however, greatly reduces coupling and only requires a simple call in the outer layer.

  • Use policies
/** * Policy interface */
public interface Strategy {
    // Policy algorithm
    void method(a);
}

/** * policy implementation class A */
public class ConcreteStrategyA implements Strategy {
    /** * policy algorithm implements A */
    public void method(a) {
        System.out.println("ConcreteStrategyA:method"); }}/** * policy implementation class B */
public class ConcreteStrategyB implements Strategy {
    /** * the strategy algorithm implements B */
    public void method(a) {
        System.out.println("ConcreteStrategyB:method"); }}/** * Context of the connection policy */
public class Context {
    private Strategy strategy;
    public void setStrategy(Strategy strategy){
        this.strategy = strategy;
    }

    /** * Policy usage */
    public void strategyMethod(a){
        this.strategy.method();
        System.out.println("Context:testMethod"); }}/ / use
    public static void main(String[] args) {
        Context context =new Context();
        // Use the ConcreteStrategyA algorithm
        context.setStrategy(new ConcreteStrategyA());
        // ConcreteStrategyA method
        context.strategyMethod();
        System.out.println("-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -");
        Use the ConcreteStrategyB algorithm
        context.setStrategy(new ConcreteStrategyB());
        // ConcreteStrategyB method
        context.strategyMethod();
    }
Copy the code

The results of

ConcreteStrategyA:method
Context:testMethod
--------------------------
ConcreteStrategyB:method
Context:testMethod
Copy the code

conclusion

The strategy pattern mainly decouples the algorithm, reducing the coupling degree of the code, and it follows the open and closed principle very well. When writing code, use design patterns to make your code more beautiful. DEMO reference: “Android source code design pattern analysis and practice”