Concept of policy pattern
The policy pattern defines a series of algorithms, encapsulates each algorithm, and makes them interchangeable. The policy pattern lets the algorithm change independently of the customers that use it.
The main character
Abstract Policy roles: Policy classes, usually implemented by an interface or abstract class.
Concrete policy roles: Wrap the associated algorithms and behaviors.
Context role: Holds a reference to a policy class that is ultimately called by the client.
Application scenarios
1. Multiple classes differ only in their behavior. The Strategy mode can be used to dynamically select the specific behavior to be executed at runtime.
2. Different strategies (algorithms) need to be used in different situations, or policies may be implemented in other ways in the future.
3. Hide the implementation details of specific strategies (algorithms) from customers, completely independent of each other.
1. The policy pattern provides a way to manage related algorithm families. The hierarchical structure of a policy class defines an algorithm or behavior family. Inheritance can be used properly to move common code into a parent class, thereby avoiding duplicate code.
2. The policy pattern provides an alternative to inheritance. Inheritance can handle a variety of algorithms or behaviors. If not in a policy pattern, then an environment class that uses an algorithm or behavior might have subclasses, each of which provides a different algorithm or behavior. In this way, however, users of the algorithm or behavior get mixed up with the algorithm or behavior itself. The logic of deciding which algorithm to use or which behavior to adopt is mixed with the logic of the algorithm or behavior and can no longer evolve independently. Inheritance makes it impossible to change algorithms or behavior dynamically.
3. Use policy patterns to avoid multiple conditional transitions. Multiple transfer statement is not easy to maintain, it takes which algorithm or take which behavior of the logic and algorithm or behavior of the logic mixed together, all listed in a multiple transfer statement, than the use of inheritance method is primitive and backward.
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 in order to choose the right algorithm class at the right time. In other words, the policy pattern only works if the client knows all the algorithms or behaviors.
2. The policy pattern creates many policy classes, and each specific policy class creates a new class. Policy classes can sometimes be designed to be shareable by storing environment-dependent state in clients, so that instances of policy classes can be used by different clients. In other words, you can use the share pattern to reduce the number of objects.
Policy Pattern instance
\r\n"; }} /** * ConcreteStrategy *2: */ implements TravelStrategy{public function TravelStrategy (){echo"travelbyTrain","
\r\n"; }} /** * ConcreteStrategy *3: */ BicycleStrategy implements TravelStrategy{public function travelAlgorithm(){echo" bicybybicycle ","
\r\n"; }} /** ** Environment class (Context): * Configured with a ConcreteStrategy object. * Maintain a reference to the Strategy object. You can define an interface that allows Strategy to access its data. */ class PersonContext{private$_strategy = null; public function __construct(TravelStrategy $travel){ $this->_strategy=$travel; } public function setTravelStrategy(TravelStrategy $travel){$this->_strategy=$travel; Public function travel(){return$this->_strategy->travelAlgorithm(); $person=new PersonContext(new TrainStrategy()); $person->travel(); $person->setTravelStrategy(new BicycleStrategy()); $person->travel(); ? >Copy the code