Strategy, also known as "plan" in ancient times, in order to achieve A certain goal, the plan will change with different goals. For example, when an agent performs A task, he must always prepare several sets of plans to deal with sudden changes. If the sudden change in the implementation of plan A makes the plan unable to continue to be implemented, he shall immediately replace it with Plan B. It is just the so-called plan is not as fast as change. Advance planning is very important, but change with the opportunity is indispensable. Only by ensuring this variable flexibility can he remain invincible. The world is always changing. The only constant is the change itself.

As a thoughtful coder, of course, we can't write the program dead. A well-designed system is not to change the code of the existing class, but to expand the class and access the system, so as to meet the needs of different users immediately.

Take the game console as an example. In the early days, Tetris was popular all over the world. Later, a kind of handheld computer was popular in China. You can only play Tetris, but it won't take long for everyone to get tired of it, so the popularity decreased, and this kind of game console soon withdrew from the market. Obviously, this is a failed design mode.

Later, Nintendo's Game Boy and Sony's PSP completely brought different user experiences. The system provided a unified card slot interface. Players can change the game as long as they change the card tape or MD, so that one machine can be used for multiple purposes.

Various game tapes make it much easier to replace games.

Well, let's start the practical part. In order to illustrate the problem, we continue to carry forward the fine tradition of minimalism. Let's make the simplest calculator. Suppose our calculator can only add and subtract. The code is as follows.

public class Calculator {//Practices that violate design pattern principles public int add(int a, int b){//addition return a + b; } public int sub(int a, int b){//subtraction return a - b; } }

Is that ok? Let's expand and think about it in the future. If our algorithms continue to increase, such as multiplication, division, power, square, etc., then this calculator class will have to be changed and changed continuously. Each time we upgrade the algorithm, we have to disassemble the machine and change the class code. Isn't this death? Will this huge system change in the end?

Or... As crazy as this?

Die! It's death! Let's change our thinking and think about it first. Since we can't write the algorithm dead in it, we must abstract the algorithm and separate the implementation details from this class into n strategies. In this case, we have two strategies, one is addition strategy and the other is subtraction strategy. They all implement the same algorithm interface, and the receiving parameters are operand a and operand b.

public interface Strategy {//Algorithm standard public int calculate(int a, int b);//Operand }

Next, the addition strategy and subtraction strategy are realized

public class Addition implements Strategy{//Implement algorithm interface @Override public int calculate(int a, int b) {//Addend and addend return a + b;//Here we do addition } } public class Subtraction implements Strategy{//Implement algorithm interface @Override public int calculate(int a, int b) {//Subtraction and subtraction return a - b;//Here we do subtraction } }

When the algorithm is written, start writing the calculator.

public class Calculator {//Calculator class private Strategy strategy;//Have some algorithmic strategy public void setStrategy(Strategy strategy) {//Access algorithm strategy this.strategy = strategy; } public int getResult(int a, int b){ return this.strategy.calculate(a, b);//Returns the result of a specific policy } }

It can be seen that the calculator class has stripped away the implementation code of the previous specific addition and subtraction algorithm. To use which algorithm, just inject it in and obtain the calculation result. getResult actually calls the calculation of the specific algorithm. Let's see how to use this calculator.

public class Client { public static void main(String[] args) { Calculator calculator = new Calculator();//Instantiation calculator calculator.setStrategy(new Addition());//Access addition implementation int result = calculator.getResult(1, 1);//calculation! System.out.println(result);//The result of addition is 2 calculator.setStrategy(new Subtraction());//Access subtraction again result = calculator.getResult(1, 1);//calculation! System.out.println(result);//The result of subtraction is 0 } }

The notes have been written very clearly. I believe everyone understands them. Then our calculator can be said to have the scalability of algorithm strategy. If there is a new algorithm in the future, there is no need to change any existing code. We only need to write a new algorithm, such as Multiplication multiplication, and implement the calculate method. The next thing to do is to assemble it and use it.