The policy pattern--defining the algorithm family, which is individually encapsulated so that they can be replaced by each other, allows the algorithm to change independently of the client using the algorithm.
Define a duck, a duck and a flight, but the motions are not the same, so here is the algorithm of change,
To apply the strategy mode, the flight action should be brought forward.
Define the interface of the flight action
Public interface Flybehavior {
public void Fly ();
}
The realization of flight movements of ducks that do not fly:
public class Flynoway implements Flybehavior {
@Override
public void Fly () {
System.out.println ("I Can not Fly");
}
}
The realization of the flying action of a duck flying with wings:
public class Flywithwings implements Flybehavior {
@Override
public void Fly () {
SYSTEM.OUT.PRINTLN ("Im flying");
}
}
The realization of the flying action of a duck flying with a rocket:
public class Flyrocketpowered implements Flybehavior {
@Override
public void Fly () {
System.out.println ("I am flying with a rocket");
}
}
Duck Super class use:
Public abstract class Duck {
Combine the duck's flying action with the duck to form a flying duck
Flybehavior Flybehavior;
Public Duck () {
}
public abstract void display ();
Define the action of a duck flight
public void Performfly () {
Flybehavior.fly ();
}
A way to set a duck's flight, a duck can change the flight movement at run time.
public void Setflybehavior (Flybehavior flybehavior) {
This.flybehavior = Flybehavior;
}
}
Implementation of a specific duck class:
Deichgraf Duck:
public class Gea extends Duck {
Public Gea () {
Flybehavior = new Flynoway ();
}
@Override
public void display () {
System.out.println ("I am a model duck");
}
}
Test class:
public class Modelduck {
public static void Main (string[] args) {
Duck model = new Gea ();
Deichgraf Ducks that don't fly
Model.performfly ();
Change flight status at runtime
Model.setflybehavior (New flyrocketpowered ());
Duck.performfly ();
}
}
The policy model has some of the following advantages:
1) Correlation algorithm series The Strategy class defines a series of algorithms or behaviors that can be reused for the client. Inheritance helps to extract public functionality from these algorithms.
2) provides a way to replace an inherited relationship: inheritance provides another way to support multiple algorithms or behaviors. You can generate a subclass of a parent class directly, giving it a different behavior. But this will make the behavior hard line into the subclass, and the implementation of the algorithm and the implementation of the subclass to mix up, so that the subclass is difficult to understand, difficult to maintain and difficult to expand, and can not dynamically change the algorithm. Finally you get a bunch of related classes, the only difference between them is the algorithm or behavior they use. Encapsulating the algorithm in a separate strategy class allows you to change it independently of its clients using classes, making it easy to switch, easy to understand, and easy to extend.
3) Elimination of some if else condition statements: The strategy pattern provides an alternative to selecting the desired behavior with a conditional statement. When different behaviors are stacked in a class, it is difficult to avoid using conditional statements to choose the appropriate behavior. These conditional statements are eliminated by encapsulating the behavior in a separate strategy class. Code that contains many conditional statements often means that you need to use the strategy pattern.
4) The choice of implementation strategy mode can provide different implementations of the same behavior. Customers can choose from different strategies based on different time/space tradeoffs.
Policy Mode Disadvantages :
1) The client must know all the policy classes and decide for itself which policy class to use: This model has a potential disadvantage, that is, a customer to choose a suitable strategy must know how these strategy are different. You may have to expose your customers to specific implementation issues at this point. Therefore, you need to use Strategy mode only when these different behavior variants are related to customer behavior.
2) communication overhead between strategy and duck: Regardless of whether the algorithms implemented by each strategy are simple or complex, they share strategy defined interfaces. Therefore, it is possible that some duck will not use all of the information passed to them through this interface; simple duck may not be using any of them! This means that sometimes duck will create and initialize some parameters that will never be used. If there is such a problem, there will need to be tighter coupling between strategy and duck.
3) Policy mode will result in many policy classes: You can reduce the number of objects to some extent by using the enjoy meta mode. Increase the number of objects strategy increases the number of objects in an app. Sometimes you can reduce this overhead by implementing strategy as a stateless object that can be shared by each duck (no instance property, or an object with an instance property of private). Any remaining state is maintained by duck. Duck passes this state to each request for the Strategy object. Shared strategy should not maintain state between invocations.
Policy mode (strategy)