Spring中的配置如何保证可扩展性

公司项目引用了一个依赖jar,配置封装太封闭了,不能扩展。业务变动一次那个jar就要跟着升级一次,而且不同的项目还引用了这个jar的不同版本。领导问我能不能给它搞成可扩展的,研究了一下,实现了可扩展定制化。

原本的配置类似是这样的:

@Configuration(proxyBeanMethods = false)
public class MyConfiguration {

    /**
     * bean
     */
    @Bean
    ConfigBean configBean(Config config)  {
        //todo 逻辑
     return new ConfigBean(config)
    }     
}

如果想根据项目的不同定制不同的ConfigBean就不太好弄了。如果能在Config对象传入ConfigBean构造之前放一个修改Config的口子就好了。这样ConfigBean的初始化生命周期也变成了

发现Config对象-> 修改Config对象-> 初始化ConfigBean

于是我定义了一个可以修改Config对象的接口:

@FunctionalInterface
public interface ConfigCustomizer {

    /**
     * Customize.
     *
     * @param config the config
     */
    void customize(Config config);
}

上面整个配置就变成这样的了:

@Configuration(proxyBeanMethods = false)
public class MyConfiguration {
    private List<ConfigCustomizer> configCustomizers = Collections.emptyList();
    /**
     * bean
     */
    @Bean
    ConfigBean configBean(Config config)  {
        
        // 其它公共逻辑省略
        
        // 最后定制逻辑注入
        configCustomizers
                .forEach(configCustomizer -> configCustomizer.customize(config));
     return new ConfigBean(config)
    }
    
    @Autowired(required = false)
    void setConfigCustomizers(List<ConfigCustomizer> configCustomizers) {
        this.configCustomizers = configCustomizers;
    }
}

这样我们需要改动配置时只需要声明一个ConfigCustomizerBean即可,它会被setConfigCustomizers自动发现并执行自定义的方法。

这里会有朋友说@ConditionalOnMissingBean系列注解也能干这个事啊,没错!这样我们完全可以声明一个新的ConfigBean取而代之。但是这是两种策略:一种是修修补补就能用一种是推到重来。我们在封装组件的时候要合理利用这些策略,该开口子的要开口子,不该开放的保持封闭,另外保证组件的扩展性也是很重要的。好了今天的分享就到这里,请多多关注:码农小胖哥,请点赞、转发、再看、分享。

中小项目用ELK做日志?我准备玩点新花样

2021-05-13

如何在代码中获取Java应用当前的版本号?

2021-05-11

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

码农小胖哥

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值