通用系统设计之优惠卷

前言

本应该继续连载手撸框架系列文章的。但最近有一个需求 -> 优惠卷，以前不少朋友让我出一篇优惠卷相关的文章。这不，本章应了大伙的愿。开始我本身的表演 🔥🔥

额,这里还要插一句，有不少新人感受在使用框架的过程当中根本用不到PHP的不少概念，例如abstract,final 部分人感受protected,private 都没有太大用处。更别提interface在框架中的使用了，感受好无用处的举爪～

策略模式

优惠卷的存在到消亡至少要经历三个步骤（建立->使用->失效），如下为优惠卷完整生命周期图，

优惠卷有几百种几千种的优惠（骗人）方式（姿式），结合PHP代码来解决优惠卷应如何建立更合适，首先先建立一个类做为优惠卷的模版

class UserCouponTem
{
}

这个模版则是一个树根，将来全部优惠卷都要经过这个根去扩展，接下来建立一系列的优惠卷参数，例如与设计数据表同样,以下所示，经过成员变量的方式，束缚了优惠卷的具体字段。

/**
 * @var $couponName
 * @content 优惠券名称
 */
public $couponName;

/**
 * @var $alidityv
 * @content 有效期
 */
public $alidityv;

/**
 * @var $userId
 * @content 绑定的用户编码
 */
public $userId;

/**
 * @var $price
 * @content 抵扣金额
 */
public $price;

/**
 * @var $type
 * @content 类型 0 通用红包 1 查看扩展字段
 */
public $type;

/**
 * @var $extend
 * @content 扩展字段
 */
public $extend;

/**
 * @var $numbers
 * @content 卷号
 */
public $number;

/**
 * @var $content
 * @content 卷内容
 */
public $content;

优惠卷的模版建立完成后，接下来须要建立两个方法，第一个为服务提供者,规定每一个建立优惠卷的类都必须存在create方法，没错，这是在写一个策略模式。

interface CouponInterface
{
    public function create($userId, $price);
}

public function provider(CouponInterface $coupon, $userId, $price)
{
    return $coupon->create($userId, $price);
}

最后是一个消费者

public function consumer($number)
{
    // $number 是卷号，这里通常都是操做redis，mysql的统一逻辑。
}

写好了一个简单的策略模式，那开始写一个策略吧。

使用策略

下方代码建立了一个通用红包。继承模版类中的字段而且去实现接口create方法

class Current extends UserCouponTem implements CouponInterface
{
    public function create($userId, $price)
    {
        $this->couponName = "通用红包";
        $this->alidityv   = "2019-01-09";
        $this->content    = "这是一个通用红包";
        $this->userId     = $userId;
        $this->price      = $price;
        $this->type       = 0;
        $this->extend     = [];
        $this->number     = '123456';
        
        return $this;
    }
}

最后经过下方代码建立一个通用红包,得到完整的一个优惠卷实例，最后将参数插入到数据库与用户表绑定则完成了一个基本的

$userCouponTem = new UserCouponTem();
$current       = $userCouponTem->provider(new Current(), $this->request->user_id,
$this->request->price);

设计思想

部分人会怀疑这种设计是画蛇添足，直接将逻辑设计到数据表不就OK了嘛？咱们为什么还要经过模版类，接口，服务提供者、服务容器去返回一个优惠卷实例？

试想不可能一次性将全部优惠卷的类型所有想到而且设计出来，数据表结构也不能频繁去更改。如何让一批代码适应整个业务而且对将来业务可扩展？这样的话则不能把全部逻辑存放到数据表中。这样作可能有如下几点好处

• 可扩展性强，可以应对各类优惠卷的表达方式
• 可维护性强，若是有新类型的业务可直接经过服务容器注入
• 代码优雅，便于阅读，不管是新入职员工仍是他人都很容易读写优惠卷的代码（比较优惠卷的业务实际很复杂）

上述实际就是Laravel的服务提供者、服务容器的概念，不明白的童鞋可去看文档并参考本例子。

数据结构

仅供参考(不是太认真的设计)
用户优惠卷表

CREATE TABLE `member_coupon` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `user_id` int(11) NOT NULL COMMENT '用户编码',
  `number` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '卷号',
  `content` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '卷内容',
  `price` decimal(8,2) NOT NULL COMMENT '金额',
  `alidityv` datetime NOT NULL COMMENT '到期时间',
  `status` tinyint(4) NOT NULL DEFAULT '0' COMMENT '-1 过时 0 未使用 1 已使用',
  `use_date` int(11) NOT NULL DEFAULT '0' COMMENT '使用时间',
  `created_at` timestamp NULL DEFAULT NULL,
  `updated_at` timestamp NULL DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

优惠卷记录表

CREATE TABLE `coupon_record` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `user_id` int(11) NOT NULL COMMENT '用户编码',
  `number` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '卷号',
  `price` decimal(8,2) NOT NULL COMMENT '金额',
  `json_content` text COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '具体json信息',
  `created_at` timestamp NULL DEFAULT NULL,
  `updated_at` timestamp NULL DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

致谢

但愿每篇文章并非仅仅讲一件问题，我会把问题的扩展思想一并告诉你们，但愿能够帮助到你。谢谢