Strategy Design Pattern Understanding

In our development process, often because the initial structure is not reasonable and may cause the back of the customer or project manager to change the requirements, we need to modify the original code, on the one hand is likely to write a long time to review the trouble, on the other hand is reaching, change a place cause all the places need to change, This shows how important a good architecture is. So today we are going to talk about a strategy design pattern to define a framework that is conducive to expansion.

  For example, we develop a game if there is a need to define a role, a weapon attack, a weapon defense, then we may feel very simple, and then the first definition of a direct definition of a parent class, plus a subclass implementation, the code is as follows: Abstract class  Role {    protected String name;      Protected abstract void attack ();     protected abstract  Void defend ();  } subclasses are implemented as follows:class rolea extends role {      Public rolea (String name)  {        this.name =  name;    }     protected void attack ()  {         system.out.println ("Dolan Sword");    }      protected void defend ()  {         system.out.println ("Dolan Shield");    }}  so this time the project manager tells you to change the requirements and creates a new character Mage. He also has attacks and defenses. This time you have to recreate a class class roleb extends  Role {     public roleb (String name)  {         this.name = name;    }      Protected void attack ()  {        system.out.println (" Dolan ");     }     protected void defend ()  {         system.out.println ("Dolan Shield");    }}  This time you will find that the effect of code reuse is not achieved at all, and if my character has added another attack mode, or have more than one weapon equipment, you have to change the source code, so today we first solve this code reuse and the extension of the problem, this leads to our strategy design pattern, As for the multiple attack modes, we'll show you the decorator design pattern behind us. So redefine how to define it, first of all, we extract these variable attack modes and form an interface separately://Attack Interface interface attackable{    void  Attack ();} Interface of the   //Defense   interface denfenseable{    void denfense ();}   Secondly, the attack mode we implement the attack interface alone, the defensive way to implement the defense interface alone class  Dolan Sword implements attackable{      Public void attack ()  {        system.out.println ("Dolan sword Attack Sharp");     }}  class  Dolan Shield implements denfenseable{      public void denfense ()  {         System.out.println ("Defend Me");    } } class  Dolan implements attackable{      public void attack ()  {         system.out.println ("Dolan");    }}  then we're abstracting a common parent class that defines some of the properties that are shared by each role abstract  class role{    public string name;    attackable  a;            //encapsulates the interface's reference to role, using polymorphism to make it more conducive to change     Denfenseable d;      public role () {}     public void setAttackable ( Attackable a) { &Nbsp;      this.a = a;    }      public void setdenfenseable (denfenseable d) {         this.d = d;    }     protected void  Attack ()  {                 a.attack ();         }     protected  void defend ()  {                d.denfense ();       }}  This time we need character A, like the sword Saint, You can directly create a sword Saint to implement Role class Rolea Extends role{     public rolea (String name) {        this.name = name;    }} The real call process directly rolea a = new rolea&nbsp ("Sword Saint");         a.setattackable (new  Dolan Sword);         a.setdenfenseable (new  Dolan Shield ());          a.attack ();         a.defend (); This is the reuse of code and the reduction of coupling. There was more than a swoop.   So summed up the words:

Policy mode: the establishment of behavioral family, the different behaviors are encapsulated, while each other can be substituted, the algorithm changes can be independent of the user.
Advantages: Improved reusability, decoupling behavior from users

Application Scenarios:

1, multiple classes only differ in performance behavior, you can use the Strategy mode, at run time to dynamically select the specific behavior to execute.

2. Different strategies (algorithms) need to be used in different situations, or strategies may be implemented in other ways in the future. (Specific implementation can be arbitrarily changed or expanded)

3, the customer hides the specific strategy (algorithm) Implementation details, each other completely independent.

Strategy Design Pattern Understanding