工作中常用到的设计模式-外呼场景的迭代重构

最新推荐文章于 2024-11-11 16:03:27 发布

Heloise_yangyuchang

最新推荐文章于 2024-11-11 16:03:27 发布

阅读量225

点赞数

文章标签：设计模式重构建造者模式装饰器模式

本文链接：https://blog.csdn.net/qq_35958391/article/details/124647618

版权

一、概述

目前生产场景包括催收、营销、游戏、电商、回访等各种复杂场景，场景模型字段包括客户姓名、性别、欠款金额、到期日、还款时间、还款渠道、会议地点、会议时间、会议主题等。特点在于其组成部分较多。

经过自主分析，场景模型构造不够合理，主要问题表现在：

构造组件较多，导致可以组合的构造函数太多，尤其是在模型增加字段时还需要去修改构造函数；
部分组件的构造存在一定的顺序关系，但是当前的实现没有体现顺序，导致构造逻辑比较混乱，并且存在大量重复的代码。

这里可以使用创建型模式中的建造者模式去做重构：

二、外呼场景的迭代重构

建造者模式：指将一个复杂对象的构造与它的表示分离，使同样的构建过程可以创建不同的表示。它是将一个复杂的对象分解为多个简单的对象，然后一步一步构建而成。它将变与不变相分离，即产品的组成部分是不变的，但每一部分是可以灵活选择的。建造者模式的主要角色如下:

产品角色（Product）：它是包含多个组成部件的复杂对象，由具体建造者来创建其各个零部件。
抽象建造者（Builder）：它是一个包含创建产品各个子部件的抽象方法的接口，通常还包含一个返回复杂产品的方法 getResult()。
具体建造者(Concrete Builder）：实现 Builder 接口，完成复杂产品的各个部件的具体创建方法。
指挥者（Director）：它调用建造者对象中的部件构造与装配方法完成复杂对象的创建，在指挥者中不涉及具体产品的信息。

通常使用Builder的构建方式，不过目前大多使用 Lombok的@Builder注解

这种设计一方面封装性好，构建和表示分离；另一方面扩展性好，各个具体的建造者相互独立，有利于系统的解耦。

到这里业务又发生了变化，要加上对应的分控校验，这个就是我之前写的三方系统黑名单接口。但是有的客户又不需要校验，所以这里可以使用装饰器模式。

装饰器模式：指在不改变现有对象结构的情况下，动态地给该对象增加一些职责（即增加其额外功能）的模式，它属于对象结构型模式。装饰器模式主要包含以下角色：

抽象构件（Component）角色：定义一个抽象接口以规范准备接收附加责任的对象。
具体构件（ConcreteComponent）角色：实现抽象构件，通过装饰角色为其添加一些职责。
抽象装饰（Decorator）角色：继承抽象构件，并包含具体构件的实例，可以通过其子类扩展具体构件的功能。
具体装饰（ConcreteDecorator）角色：实现抽象装饰的相关方法，并给具体构件对象添加附加的责任。

// 抽象装饰角色
abstract class ActivityDecorator implements ActivityInterface {
    protected ActivityInterface activity;
    public ActivityDecorator(ActivityInterface activity) {
        this.activity = activity;
    }
    public abstract void participate(Long userId);
}
// 做风险控制的包装类
class RiskControlDecorator extends ActivityDecorator {
    public RiskControlDecorator(ActivityInterface activity) {
        super(activity);
    }
    @Override
   public void participate(Long userId) {
        // 对目标用户做风险控制，失败则抛出异常
       Risk.doControl(userId);
        // 更新任务状态为进行中
        activity.participate(userId);
    }
}