Design Pattern Series 2 (strategizer pattern)

I am confused. I really don't know how to position my own life? With lofty ambitions, you can't do anything! There is a saying that when your talents cannot support your ambitions, you should calm down and study hard! So when I had nothing to do, I began my design model tour! Today, we will study the rule-by mode!

1. Analysis of the policyholder Mode

The pattern of big talk design is as follows:

The strategizer mode is a method that defines a series of algorithms. From a conceptual point of view, all these algorithms perform the same job, but they only implement differently, it can call all algorithms in the same way to reduce the coupling between various algorithm classes and algorithm classes [DPE].

Personal Understanding: A series of algorithm methods are a series of classes, that is, each algorithm corresponds to a class. It can call all algorithms in the same way, this is a multi-state application (Unified Call of different implementations ). So how can we call different implementations in a unified manner? The first thing we think of is that there will be a parent class and a subclass!

2. policyholder mode instance

Scenario: define two numbers randomly and calculate the result based on different symbols!

2.1 Composition of Rule Modes
Abstract policy role: a policy class, usually implemented by an interface or abstract class.

Specific policy roles: encapsulate related algorithms and behaviors to inherit abstract policy roles.

Configuration role: the Policy class is referenced and finally called by the client.

 

// Algorithm abstract class Strategy {public abstract int calculationinterface (INT num1, int num2);} class Add: Strategy {public override int calculationinterface (INT num1, int num2) {return num1 + num2 ;}} class subtraction: Strategy {public override int calculationinterface (INT num1, int num2) {return num1-num2 ;}}

Simple factory implementation:

// Implement class calculationfactory {public static strategy createcalculationinterface (string type) {strategy Sy = NULL; Switch (type) in a simple factory) // instantiate different algorithm classes based on different types {Case "+": Sy = new add (); break; Case "-": Sy = new subtraction (); break ;} return Sy ;}} static void main (string [] ARGs) {int num1 = 10, num2 = 6; strategy Strategy = calculationfactory. createcalculationinterface ("+"); console. writeline (strategy. calculationinterface (num1, num2); strategy = calculationfactory. createcalculationinterface ("-"); console. writeline (strategy. calculationinterface (num1, num2); console. readline ();}

Resolution:

We only need to pass the corresponding conditions to get the desired object, and then implement algorithm operations through this object!

 

Rule mode implementation:

// Policy mode implementation // create a class to configure reference class context {strategy Strategy; public context (strategy Strategy) for the strategy object // during initialization, specify the policy object {This. strategy = strategy;} // context interface public int getresult (INT num1, int num2) {return strategy. calculationinterface (num1, num2); // call the algorithm based on the specific policy object} static void main (string [] ARGs) {int num1 = 10, num2 = 6; context context; Switch (type) // instantiate different algorithm classes based on different types {Case "+": context = new context (new add (); break; Case "-": context = new context (New subtraction (); break;} console. writeline (context. getresult (num1, num2); console. readline ();}

Resolution:

You must first create a class object that you want to use, then pass the most parameters of the object, and call different algorithms through the object;

But there are still some shortcomings: the judgment process ran to the client again, But how should we transfer the judgment process from the client? Then combine the factory with the policy model.

 

Factory implementation in combination with policy mode:

// Combination of policy mode and simple factory; Class context {strategy _ startrgy = NULL; public context (string type) // at this time, it is not a specific policy object but a string {Switch (type) // instantiate different algorithm classes {Case "+": _ startrgy = new add (); break; Case "-": _ startrgy = new subtraction (); break ;}} public int getresult (INT num1, int num2) {return _ startrgy. calculationinterface (num1, num2) ;}} static void main (string [] ARGs) {int num1 = 10, num2 = 6; Context context = new context ("+ "); console. writeline (context. getresult (num1, num2); // instantiate different policies to obtain different results. Context = new context ("-"); console. writeline (context. getresult (num1, num2); console. readline ();}

2. Comparison between simple factory and simple factory Combination Strategy Mode

// Simple factory strategy Strategy = calculationfactory. createcalculationinterface ("+ ");... = strategy. calculationinterface (...); // combine the policy mode with the simple factory context = new context ("+ ");... = context. getresult (...);

Resolution:

In a simple factory, the client needs to understand two classes: Strategy and calculationfactory. In combination with a simple factory, the client only needs to know one class: context, which reduces the coupling degree;

Summary:

Advantages:

1. Each algorithm is a separate class, which simplifies unit testing. You can use your own interfaces to test [DPE] separately.

2. Policy mode is a method that defines a series of algorithms. It can call different algorithms in the same way, reducing the coupling between various algorithm classes and algorithm classes;

Disadvantages:

1. The client needs to understand the differences between all specific policy classes in order to select an appropriate algorithm, which increases the difficulty of using the client to a certain extent;
2. Each algorithm is a strategy class, which may cause many policies, making the system huge and difficult to maintain;

 

Legacy problems:

Whether it is a simple factory or a combination of a simple factory and a policy model, there is always a problem: the switch is used, that is, if we need to add an algorithm, you must change the switch code in the context. This is always unpleasant!

Of course, there is still a solution. The specific solution will be discussed later!

Today's policy model is written here. I hope you will give me more advice!