【设计模式-桥接模式】的日常使用

之前发现工厂模式能干掉代码里面大量的if else的混乱代码。我又在研究我的一坨代码的地方。发现有个场景适合桥接模式。其实重构自己的代码的点其实很简单,从你原来开发的一坨代码上好好研究下业务逻辑就会发现都是可以优化的地方。毕竟这些长业务的地方如果不优化,之后上新业务去改这些地方,测试你会发现要把老流程全走一遍会非常头疼。所以优化是势在必行的。
桥接模式的主要作用就是通过将抽象部分与实现部分分离,把多种可匹配的使用进行组合。说白了核心就是在A类中含有B类的接口,通过构造函数传递B类的实现,这个B类就是设计的桥。(来源于《重学Java设计模式》)
根据作者的例子他的场景里面支付方式和支付的验证有多种,且是组合的一种方式。刚好我这里有个开发场景也是这种组合式的方式。我现有业务是要给一个任务去分配可用的实例去执行。分配之前需要去注册中心去获取可以实例数里面剩余线程数量,如果有空余就分配。在早期版本没有在微服务里面实现时,所以服务是没有注册到注册中心,是下层服务主动请求管理服务,管理服务用redis去保存心跳。然后任务下发的时候去redis里面校验。后来服务升级为微服务后,服务全部注册到zookeeper上,校验的方式从redis获取替换为从zookeeper上获取。在没用设置模式时,我的改造是把原来redis实现部分删了,然后替换为zookeeper然后测试的时候怕出错,就把整个流程都测了,开发时间很大。如果使用桥接模式,把一开始的实例线程获取情况用接口是实现,在需求变更后,只需要写测试时测试通过zookeeper获取实例情况的代码即可,这即增加了代码的拓展性又缩短了测试时间。

   --task
   --- ManyPictureTaskService.java
   --- OnePictureTaskService.java
   --- PictureTaskService.java
   --distribution
   --- RedisPictureScoreDistribution.java
   --- ZookeeperScoreDistribution.java
   --- PictureScoreDistribution.java
   -- PictureTaskFactory.java

代码目录可以看出来我这里有2个任务类型一个的单张图片获取,一个是多张图片获取。任务分配能力有redis校验方式,zookeeper校验方式。定义一个PictureTaskService抽象类,在里面引用PictureScoreDistribution接口。然后实现ManyPictureTaskService和OnePictureTaskService。最后结合工厂模式把2个实现类由PictureTaskFactory获取。当http请求过来的时候,会带上taskType,根据这个值就可以在factory里面获取到任务要调用的是哪个图片获取方法了。distribution里面的分配方法由于一个服务只有一个实现,所以在类上面结合Springboot的注解@ConditionalOnProperty来激活。这样在未来如果分配方法又有新需求变更了,我们只需要实现接口,然后在配置文件里面增加配置属性就可以直接切换分配的实现。如果切图方法有多张,单张增加新的需求,也只要实现切图任务接口,这样测试起来就不需要再去主流程里面测对单张切图,多张切图有没有影响了。

贴代码

/**
 * 切图任务业务
 */
public abstract class PictureTaskService {
   
    public PictureTaskService(PictureScoreDistribution pictureScoreDistribution) {
   
        this.pictureScoreDistribution = pictureScoreDistribution;
    }

    protected PictureScoreDistribution pictureScoreDistribution;

    /**
     * 创建切图任务
     *
     * @param body
     * @return
     */
    public abstract ResultData createTask(TaskRouteBody body);
}
/**
 * 可用实例获取方法
 */
public interface PictureScoreDistribution {
   
    JSONObject getServer();
}
/**
 * 通过redis zset方式获取到可用的instance
 */
@Slf4j
@Component
@ConditionalOnProperty
public class RedisPictureScoreDistribution implements PictureScoreDistribution {
   
    @Autowired
    private RedisTemplate<String, Object> redisTemplate;
    @Autowired
    private StringRedisTemplate stringRedisTemplate;
    private static final Long HEADER_INDEX = 0L;
    private static final Long FIRST_END_INDEX = -1L;

    @Override
    public JSONObject getServer() {
   
        Set<ZSetOperations.TypedTuple<Object>> typedTuples = redisTemplate.opsForZSet().reverseRangeWithScores(RegexConstants.REDIS_KEY_PICTURE_NODES, HEADER_INDEX, FIRST_END_INDEX);
        if (
  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值