设计模式之 策略模式
策略模式属于对象行为型的设计模式
定义 ：封装了一些列算法，它们之前可以相互替换，此模式使得算法的改变，不会影响到使用它们的客户端
策略模式有以下3个角色组成
抽象策略类 ： 所有策略类的父类，为所支持的策略算法声明了抽象方法
具体策略类 ：实现抽象策略类的方法
Context环境类 ： 维护一个对Strategy对象的引用
策略模式分离了算法的定义和使用，要做到这样客户端要依赖于策略接口，而不是具体的实现所有策略类对象可以互相替换，说明具有共同的特性->行为相同
以下是PHP对上述UML的实现
<?php
/*
*抽象策略类
*/
abstract class Stratrgy{
abstract function AlgorithmInterface();
}
//具体实现类A
class ConcreateStratrgyA extends Stratrgy{
public function AlgorithmInterface() {
echo '算法A', PHP_EOL;
}
}
//具体实现类B
class ConcreateStratrgyB extends Stratrgy{
public function AlgorithmInterface() {
echo '算法B', PHP_EOL;
}
}
//具体实现类C
class ConcreateStratrgyC extends Stratrgy{
public function AlgorithmInterface() {
echo '算法C', PHP_EOL;
}
}
//上下文环境类
class Context{
private $_strategy;
//通过构造方法注入策略对像
public function __construct(Stratrgy $strategy) {
$this->_strategy = $strategy;
}
public function ContextInterface(){
$this->_strategy->AlgorithmInterface();
}
}
//客户端类
class Client{
public static function main(){
$context = new Context(new ConcreateStratrgyA());
$context->ContextInterface();
$context = new Context(new ConcreateStratrgyB());
$context->ContextInterface();
$context = new Context(new ConcreateStratrgyC());
$context->ContextInterface();
}
}
Client::main();在实际开发中，我们项目里很多地方都用到了策略模式，这里以支付回调为栗子介绍下策略模式在我们项目中的应用。
首先所有的支付回调都是由第三方发起，行为相同，最终都是给用户发送道具并通知第三方。整个流程可以抽象为3个步骤 ：验证第三方参数 ->发送道具给用户 ->返回报文给第三方,因此我们的抽象策类里可以定义3个抽象方法，另外一些公共使用的方法都可以放到抽象
策略类里，具体策略类只需要继承就可以复用。策略环境类这里做了一些改动，加入了简单工厂模式生成具体的策略对象。每种支付的参数验证，发具体的道具数，以及报文响应都不相同，具体的支付类需要实现3个抽象方法。
由微信切换成支付宝，需要增加对应的支付宝类，然后回调的时候在工厂方法传入支付宝参数即可，这样微信，支支付宝...达到了相互替换的目的，而且具体的支付宝微信类改变不会影响到回调的入口。
抽简后的代码如下：
<?php
//抽象策略类
abstract class StrategyNotify{
//参数检查
abstract function checkParam();
//发送道具
abstract function sendProp();
//输出报文
abstract function outputMessage();
//支付回调状态
protected $_status = -1;
//第三方参数
protected $_params = array();
protected $_errMsg = array(
'-1'=>'系统错误',
'-2'=>'参数验证错误',
'-3'=>'发送道具失败',
);
//通知方法
public final function notify(){
if(!$this->checkParam()){
$this->_status = -2;
}else if(!$this->sendProp()){
$this->_status = -3;
}else{
$this->_status = 1;
}
if($this->_status != 1){
$this->log();
}
$this->outputMessage();
}
//写日志例子
protected function log(){
echo isset($this->_errMsg[$this->_status]) ? $this->_errMsg[$this->_status] : '';
echo PHP_EOL;
}
}
//微信支付
class Weixin extends StrategyNotify{
public function checkParam() {
return false;
}
public function outputMessage() {
if($this->_status === 1){
die('OK');
}else{
die('FAIL');
}
}
public function sendProp() {
return false;
}
}
//支付环境类
class Pay{
private static $_notify = null;
//策略工厂
public static function factory($notify){
if(class_exists($notify) && self::$_notify == null){
self::$_notify = new $notify();
}
return self::$_notify;
}
}
Pay::factory('Weixin')->notify();总结
优点:
1.当新增策略的时候，只需要增加具体的策略类，达到了开闭原则的目的
2.分离了算法的定义和使用，使得算法可以复用
缺点
1.每增加一个策略就需要增加一个策略类(目前我们的app接近200种支付，意味着有200个子类)
2.无法在客户端同时使用两种策略(我们的支付下单,需要从多种支付依照优先级一个个去下单，直到成功为止)