前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >设计模式之 策略模式

设计模式之 策略模式

作者头像
用户3094376
发布2018-09-12 11:05:32
3960
发布2018-09-12 11:05:32
举报
文章被收录于专栏:gaoqin31

策略模式属于对象行为型的设计模式

定义 :封装了一些列算法,它们之前可以相互替换,此模式使得算法的改变,不会影响到使用它们的客户端

策略模式有以下3个角色组成

抽象策略类 : 所有策略类的父类,为所支持的策略算法声明了抽象方法

具体策略类 :实现抽象策略类的方法

Context环境类 : 维护一个对Strategy对象的引用

策略模式分离了算法的定义和使用,要做到这样客户端要依赖于策略接口,而不是具体的实现所有策略类对象可以互相替换,说明具有共同的特性->行为相同

以下是PHP对上述UML的实现

代码语言:javascript
复制
<?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个抽象方法。

由微信切换成支付宝,需要增加对应的支付宝类,然后回调的时候在工厂方法传入支付宝参数即可,这样微信,支支付宝...达到了相互替换的目的,而且具体的支付宝微信类改变不会影响到回调的入口。

抽简后的代码如下:

代码语言:javascript
复制
<?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.无法在客户端同时使用两种策略(我们的支付下单,需要从多种支付依照优先级一个个去下单,直到成功为止)

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2017-10-16 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档