关于采编系统的设计与分析

一个采编系统，核心无非就是写作，审核，发布这些基本的流程。处理好这个部分，一个采编系统就该就差不多了。

写作，审核，发布。从编程的角度来看，它们其实是一个个的事件。审核是一个事件，发布是一个事件，取消发布是一个事件，推荐是一个事件。而这些是事件改变的是文章的状态。

首先就是一个文章类，简单化，一个id 表示唯一标识，一个status 标识文章状态。

class ArticleModel
{
    public $id;
    public $status;
}

其次，这个应该是事件驱动的，那么定义接口和抽象类

interface IArticleEvent{
    public function action(ArticleModel $articelModel);
}

abstract class ArticleEvent implements IArticleEvent{    
    //保存
    const SaveArticle = 1;
    //提交
    const SubmitArticle = 2;
    //第一次审核
    const FirstReviewArticle = 4;
    //第二次审核
    const SecondReviewArticle = 8;
    //发布
    const PublishArticle = 16;
    //A推荐
    const ARecommendArticle = 32;
    //B推荐
    const BRecommendArticle = 64;

    public $event_name;
    public $created_at;
    public $created_by;

    public function __construct($event_name,$created_at,$created_by){
        $this->event_name = $event_name;
        $this->created_by = $created_at;
        $this->created_by = $created_by;
    }

    public abstract function action(ArticleModel $articelModel);
}

一般用状态最好用二级制 1，2，4，6，8...表示。这个其一和1，2，3，4没有什么区别，其二就是它可以表示累加，1+2+4 = 7。
这里的流程是，保存状态->提交状态->第一次审核状态->第二次审核状态->发布状态->(A推荐状态，B推荐状态) 。
这里status就可以很灵活，既可以是1，2，4，8。也可以是状态相加，比如说 文章是 A推荐状态 1+2+4+8+16+32 = 63。文章同时A推荐也是B推荐，就是127。文章取消A推荐，就是95，仅仅是发布状态就是 31。

最后就是实现各个事件了。这里就简单实现三个事件。提交，A推荐和取消A推荐

class PublishArticleEvent extends ArticleEvent {

    public function action(ArticleModel $articelModel)
    {
        $status = $articelModel->status + ArticleEvent::PublishArticle;
        echo "提交文章成功 文章状态 ".$status;
    }
}

class ARecommendArticle extends ArticleEvent
{

    public function action(ArticleModel $articelModel)
    {
        $status = $articelModel->status + ArticleEvent::ARecommendArticle;
        echo "A推荐 文章进入到B推荐（文章可以同时是提交状态和A推荐状态） ". $status;
    }
}

class CancelARecommendArticle extends ArticleEvent
{
    public function action(ArticleModel $articelModel)
    {
        $status = $articelModel->status - ArticleEvent::ARecommendArticle;
        echo "取消A精选成功 文章返回到提交状态 ".$status;
    }
}

目前流程比较简单，就是简单的加，减法。也可以在这里去处理sql语句之类的。

这样是事件驱动，符合单一原则和开放-关闭原则。代码就会很灵活，扩展也会很方便，流程控制代码和事件代码分离。
比如说，在Article实现通用的日志记录方法 function log()。在特定的类下面，重写这个log方法。用于记录更加详细的日志信息。
再比如说， 流程中加一个第三次审核，加一个事件ThirdArticleReviewEvent,将这个类加入到流程控制代码中。
取消A推荐这个事件，要求不仅取消A的推荐，同时也是取消A的发布。那么加一个新事件，或者只需要修改单一事件。
在上面的需求再改一下。A部门可以同时取消推荐和发布，B部门只能取消推荐。那么加一个新的事件。

这种基本可以做到他自狠来他自恶，我自一口真气足。