[[399692]]

公司項(xiàng)目引用了一個(gè)依賴(lài)jar，配置封裝太封閉了，不能擴(kuò)展。業(yè)務(wù)變動(dòng)一次那個(gè)jar就要跟著升級(jí)一次，而且不同的項(xiàng)目還引用了這個(gè)jar的不同版本。領(lǐng)導(dǎo)問(wèn)我能不能給它搞成可擴(kuò)展的，研究了一下，實(shí)現(xiàn)了可擴(kuò)展定制化。

原本的配置類(lèi)似是這樣的：

@Configuration(proxyBeanMethods = false) 
public class MyConfiguration { 
 
    /** 
     * bean 
     */ 
    @Bean 
    ConfigBean configBean(Config config)  { 
        //todo 邏輯 
     return new ConfigBean(config) 
    }      
} 

如果想根據(jù)項(xiàng)目的不同定制不同的ConfigBean就不太好弄了。如果能在Config對(duì)象傳入ConfigBean構(gòu)造之前放一個(gè)修改Config的口子就好了。這樣ConfigBean的初始化生命周期也變成了

發(fā)現(xiàn)Config對(duì)象-> 修改Config對(duì)象-> 初始化ConfigBean 

于是我定義了一個(gè)可以修改Config對(duì)象的接口：

@FunctionalInterface 
public interface ConfigCustomizer { 
 
    /** 
     * Customize. 
     * 
     * @param config the config 
     */ 
    void customize(Config config); 
} 

上面整個(gè)配置就變成這樣的了：

@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; 
    } 
} 

這樣我們需要改動(dòng)配置時(shí)只需要聲明一個(gè)ConfigCustomizerBean即可，它會(huì)被setConfigCustomizers自動(dòng)發(fā)現(xiàn)并執(zhí)行自定義的方法。

這里會(huì)有朋友說(shuō)@ConditionalOnMissingBean系列注解也能干這個(gè)事啊，沒(méi)錯(cuò)!這樣我們完全可以聲明一個(gè)新的ConfigBean取而代之。但是這是兩種策略：一種是修修補(bǔ)補(bǔ)就能用;一種是推到重來(lái)。我們?cè)诜庋b組件的時(shí)候要合理利用這些策略，該開(kāi)口子的要開(kāi)口子，不該開(kāi)放的保持封閉，另外保證組件的擴(kuò)展性也是很重要的。

本文轉(zhuǎn)載自微信公眾號(hào)「碼農(nóng)小胖哥」，可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系碼農(nóng)小胖哥公眾號(hào)。