[Reading Notes-reconstruction and mode] Strategy Mode strategy-encapsulation change

Strategy Mode:

Define a series of algorithms, encapsulate them one by one, and they can replace each other. The strategy mode enables the algorithm to change independently of the users who use it.

Specifically, key features of the policy model include:

Intent: You can use different business rules or algorithms based on the context. Problem: the selection of the desired algorithm depends on the user who sends the request or the data to be processed. This mode is not required if there are only algorithms that do not change. Solution: The algorithm selection and implementation are separated. Select Based on the context. Participants and collaborators :......... Effect: defines a series of algorithms. It is not applicable to conditional statements or switch statements. Each algorithm has the same interface. Implementation: Let the class using an algorithm include an abstract class which has an abstract method to specify how to call an algorithm. Each derived class implements algorithms as needed.

Based on some object-oriented advice: "consider what is variable in Design", "encapsulate the concept of change", and "prioritize object combination clustering rather than class inheritance ". Therefore, our practice is:

1. Look for changes and encapsulate them in a separate class. 2. Include this class in another class.

An example of the policy pattern given in "going deep into PHP object-oriented patterns and practices:

Suppose we have already picked up a markup language, and now the test requires some problems, so we created the Question class and added the mark () method for it. What should I do if a user can use multiple tag methods to answer a question?

For example, you need to support the simple marklogic language, direct matching, and regular expression matching. The first thing that comes to mind is to use subclasses for implementation.

If this is the only requirement, it can still meet our needs, but if we are required to support different types = text-based and multimedia-based, the scheme of wearing multiple subclasses in an inheritance tree may cause some problems.

Therefore, "as long as you find that you are constantly repeating the same algorithm in several mature branches (whether by subclass or by repeating conditional statements) encapsulate these algorithms into independent types. ".

UML diagram:

Implementation:

abstract class Question{    protected $promp;    protected $marker;    public function __construct($promp,Marker $marker){        $this->marker = $marker;        $this->promp = $promp;    }    abstract  function mark($response);}

class TextQuestion extends Question{    public function mark($response){        echo  "[text-response:]".$response.PHP_EOL;        return $this->marker->mark($response);    }}

class AVQuestion  extends Question{    public function mark($response){        echo "[Av-response:]".$response.PHP_EOL;        return $this->marker->mark($response);    }}

class MarkLogicMarker extends Marker{    private $engine;    public function __construct( $test ){        parent::__construct($test);        $this->engine = new MarkPaser($test);    }    public function mark($response){        return $this->engine->evaluate( $response );    }}

class MatchMarker extends Marker{    public function mark($response){        return ($this->test == $response);    }}

class RegexMarker extends Marker{    public function mark($response){        return ( preg_match($this->test,$response) );    }}

class Config{    public static $configs = array(        'what is baby?'=>'yes',        'how can i love U?'=>'of course',        'may be tomorrow?'=>'yeah',        'should it be like this?'=>'maybe',        'the result is?'=>'1+1',    );}

class MarkParser{    private $test;    public function __construct($test){        $this->test = $test;    }    public function evaluate( $response ){        assert($response);        assert(in_array($response,array_keys(Config::$configs)));        return Config::$configs[$response];    }}