代码重构之解耦合

最近在对业务代码进行重构，遇到了一些比较典型的“散发着难闻味道”的代码，可以用又臭又长来形容。

这部分的业务是发布动态，包括以下步骤：

• 敏感词过滤
• 话题提取
• 动态数据入库
• 敏感词记录
• 话题及话题动态关联关系入库

之所以说重构前的代码“又臭又长”，首先最直观的一点，方法的行数超过了200行，其次上面四个步骤的逻辑全都写在了一起，没有按功能模块拆分，这也是方法过长的原因。

如果按功能划分，发布动态包含三个模块：

• 敏感词模块
• 动态模块
• 话题模块

其中的敏感词模块和话题模块都是为动态模块服务的。一个动态可以有敏感词，也可以没有敏感词，比如用户分享一个链接，这就不需要做敏感词过滤与记录了，所以敏感词模块与动态模块应该是“松耦合”的。同样，一个动态可以包含话题，也可能不包含，所以话题模块与动态模块也应该是松耦合的。

既然敏感词模块与话题模块都是为动态模块服务的，动态模块就有必要与这两个服务模块建立一个服务约定：

• 我需要什么样的服务
• 我们之间如何建立耦合关系

我需要什么样的服务

在编程的世界里，约定可以抽象成接口

interface PublishContract{    // Call this method before publishing    public function beforePublish();    // Call this method after publishing    public function afterPublish();}

对于敏感词模块和话题模块，只需要实现该接口，动态模块就可以根据约定调用它们提供的服务。

class SensitiveWords implements PublishContract{    public function beforePublish()    {        //     }    public function afterPublish()    {        //    }}

class TopicObserver implements PublishContract{    public function beforePublish()    {        //     }    public function afterPublish()    {        //    }}

这样动态模块就知道，在动态入库前调用服务模块的beforePublish服务，入库后调用服务模块的afterPublish服务。

我们如何建立耦合

耦合关系的建立应该由动态发布的调用方决定，动态模块需提供相应的接口，

class Feeds{    // PublishContract[]    protected $serviceModules = [];    public function addServiceModule(PublishContract $service)    {        $this->serviceModules[get_class($service)] = $service;    }    public function removeServiceModule($serviceClassName)    {        unset($this->serviceModules[$serviceClassName]);    }    public function publish()    {        foreach ($this->serviceModules as $service) {            $service->beforePublish();        }        // do something about publishment        foreach ($this->serviceModules as $service) {            $service->afterPublish();        }    }}

这样，动态发布的调用方可以通过addServiceModule/removeServiceModule动态地添加/删除服务模块。

UML图

重构带来的好处

松耦合

服务模块与核心模块是独立的，通过接口建立松耦合的关系；可动态添加/删除服务模块。

易于维护

服务模块的修改不会直接影响核心模块。

易于扩展

如果需要添加其它服务模块，只需实现服务约定的接口，并将新的服务模块动态添加到核心模块即可。