Review the design pattern-strategy Pattern

Review the design pattern-strategy Pattern

The design model has been learned before. This soft exam is both a review and an improvement. The soft test needs to use java to learn the design mode. Although the previous learning is C #, the design mode has the same idea. Let's talk about the theme. Next, let's take a look at what is the strategy mode.

The policy mode defines the algorithm family and encapsulates them separately so that they can be converted to each other. This mode prevents algorithm changes from affecting the customers who use the algorithm.

For example:

Now there is a duck parent class. What we need is green-headed duck and red-headed duck. You only need to write a virtual display method in the parent class and then let the subclass rewrite it. The green duck's display will implement the green head, and the red duck will implement the red head. Now it is easy to implement so that all the ducks can fly. Just add a fly Method to the parent class. Similarly, if you want all ducks to be called, you can add the quack Method to the parent class.

Now we have a rubber duck that inherits from the parent class. A rubber duck can be called but cannot scream like a real duck. It can only scream. We can only overwrite the fly method of the parent class in the Rubber Duck subclass so that it does nothing, and then overwrite the quack method to make it scream.

Now, another fake wooden duck is not flying or calling. Let it inherit the parent class and then overwrite the fly and quack methods of the parent class, so that the two methods do nothing.

In this way, both the Rubber Duck and the wooden duck are implemented, but the fly and quack methods are not required in the Rubber Duck, but I have to write it all over again to overwrite the parent class, which is just a superfluous addition. What's even more painful is to add a new duck and consider whether to overwrite the fly and quack of the parent class. What should we do?

At this time, we need to separate the parts that may change in the application without affecting other parts.

In this example, the flight behavior and calling behavior are separated from the Duck class, and the Duck class no longer needs to know the implementation details of the behavior. The class diagram is as follows:

Code implementation:

 

// Duck class public abstract class Duck {FlyBehavior flyBehavior; // instantiate the flying object QuackBehavior quackBehavior; // instantiate the object named public Duck () {} public abstract void display (); // The virtual method public void implements mfly () {flyBehavior. fly ();} public void initialize mquack () {quackBehavior. quack ();} public void swim () {System. out. println ("All ducks float, even decoys ");}}

 

 

// Public class MallardDuck extends Duck {public MallardDuck () {quackBehavior = new Quack (); flyBehavior = new FlyWithWings ();} public void display () {System. out. println ("I'm a real Mallard duck ");}}

// Flight behavior interface public interface FlyBehavior {public void fly ();}

// Implement the public class FlyWithWings implements FlyBehavior {public void fly () {System. out. println ("I'm flying! ");}}

// Do not fly to implement public class FlyNoWay implements FlyBehavior {public void fly () {System. out. println ("I can't fly ");}}

// Call the behavior interface public interface QuackBehavior {public void quack ();}

// Implement the public class Quack implements QuackBehavior {public void quack () {System. out. println ("Quack ");}}

// The behavior will not be called to implement public class MuteQuack implements QuackBehavior {public void quack () {System. out. println ("
 
  
");}}
 

// Implement the public class Squeak implements QuackBehavior {public void quack () {System. out. println ("Squeak ");}}

// Main function public class MiniDuckSimulator {public static void main (String [] args) {Duck mallard = new MallardDuck (); mallard. extends mquack (); mallard. performFly ();}}

Running result:

 

Advantages:

1. The policy mode provides methods for managing related algorithm families. The hierarchical structure of a policy class defines an algorithm or behavior family. Proper use of inheritance can transfer public code to the parent class to avoid repeated code.

 

2. The policy mode provides a way to replace the inheritance relationship. Inheritance can process multiple algorithms or actions. If the policy mode is not used, the Environment class that uses algorithms or behaviors may have some subclasses. each subclass provides a different algorithm or behavior. However, in this way, the user of an algorithm or behavior is mixed with the algorithm or behavior itself. The logic that determines which algorithm to use or which behavior to take is mixed with the logic of the algorithm or behavior, so that it is impossible to evolve independently. Inheritance makes it impossible to dynamically change algorithms or behaviors. 3. Use Policy mode to avoid using multiple conditional transfer statements. Multiple transfer statements are not easy to maintain. they mix the logic of which algorithm or behavior is adopted with the logic of the algorithm or behavior and are all listed in a multiple transfer statement, it is more primitive and backward than the inheritance method. Disadvantages: 1. The client must know all the policy classes and decide which one to use. This means that the client must understand the differences between these algorithms so that appropriate algorithm classes can be selected in a timely manner. In other words, the policy mode is only applicable when the client knows all the algorithms or actions. 2. The policy mode creates many policy classes. Each specific policy class produces a new class. Sometimes you can save the environment-dependent status to the client and design the policy class to be shared so that the policy class instance can be used by different clients. In other words, you can use the metadata mode to reduce the number of objects.