Statement: This series of blog reference "Big Talk design mode", author Geoscience.
The policy pattern defines a series of algorithms, encapsulates each algorithm, and allows them to be replaced with each other. The policy pattern makes the algorithm independent of the client using it, i.e. the algorithm that encapsulates the change.
Applicable 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.
3, the customer hides the specific strategy (algorithm) Implementation details, each other completely independent.
4. The client must know all the policy classes and decide for itself which policy class to use, and the policy pattern only applies if the client knows all the algorithms or behaviors.
5, the policy mode causes a lot of policy classes, each specific policy class will produce a new class.
Sometimes you can use the enjoy meta mode to reduce the number of objects by saving the environment-dependent state to the client.
UML Class Diagrams:
Role Analysis:
Abstract policy Role (Rotateitem): A policy class, usually implemented by an interface or abstract class.
Specific policy role (ItemX): wraps the relevant algorithms and behaviors.
Environment Role (ITEMCONTEXT): holds a reference to a policy class that is eventually called to the client.
Specific code implementation:
"; } function Uninertisrotate () {echo "I am the x product, I am not inertia rotation."
"; }}/** specific strategy role?? Y products * Class yitem */class Yitem implements rotateitem{function Inertiarotate () {echo "I am the y product, Ican'tInertia rotation.
"; } function Uninertisrotate () {echo "I am the y product, I am not inertia rotation."
"; }}/** specific strategy role?? XY product * Class Xyitem */class Xyitem implements rotateitem{function Inertiarotate () {echo "I am xy product, I rotate in inertia.
"; } function Uninertisrotate () {echo "I am xy product, I am not inertia rotation."
"; }}class contextstrategy{private $item; function GetItem ($item _name) {try {$class =new reflectionclass ($item _name); $this->item= $class->newinstance (); } catch (Reflectionexception $e) {$this->item= ""; }} function Inertiarotate () {$this->item->inertiarotate (); } function Uninertisrotate () {$this->item->uninertisrotate (); }}
Client calling Code:
X Products
"; $strategy->getitem (' Xitem '); $strategy->inertiarotate (); $strategy->uninertisrotate (); echo"y Products
"; $strategy->getitem (' Yitem '); $strategy->inertiarotate (); $strategy->uninertisrotate (); echo"XY Products
"; $strategy->getitem (' Xyitem '); $strategy->inertiarotate (); $strategy->uninertisrotate ();
Advantages:
1. The strategy mode provides a way to manage related algorithm families.
The hierarchy structure of a policy class defines an algorithm or a family of behaviors.
Proper use of inheritance can transfer common code to the parent class, thus avoiding duplicate code.
2. The policy mode provides a way to replace the inheritance relationship.
Inheritance can handle multiple algorithms or behaviors.
If the policy mode is not used, then the environment class using the algorithm or behavior may have some subclasses, each of which provides a different algorithm or behavior. However, the user of the algorithm or behavior is mixed with the algorithm or the 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 an algorithm or behavior.
3. Use the policy mode to avoid using multiple conditional transfer statements.
Multiple transfer statements are difficult to maintain, and it mixes the logic of which algorithm or behavior is taken with the logic of the algorithm or the action, all in a multiple transfer statement, more primitive and backward than the method of using inheritance.
Disadvantages:
1. The client must know all of the policy classes and decide which policy class to use at its own discretion.
This means that the client must understand the differences between these algorithms in order to select the appropriate algorithm classes at the right time. In other words, the policy pattern applies only to situations where the client knows all the algorithms or behaviors.
2, the policy mode causes a lot of policy classes, each specific policy class will produce a new class.
It is sometimes possible to design a policy class to be shareable by saving the environment-dependent state to the client, so that the policy class instance can be used by different clients. In other words, you can use the enjoy meta mode to reduce the number of objects.
PHP Object-oriented design pattern