[[399692]]

公司項目引用了一個依賴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取而代之。但是這是兩種策略：一種是修修補補就能用;一種是推到重來。我們在封裝組件的時候要合理利用這些策略，該開口子的要開口子，不該開放的保持封閉，另外保證組件的擴展性也是很重要的。

本文轉載自微信公眾號「碼農小胖哥」，可以通過以下二維碼關注。轉載本文請聯系碼農小胖哥公眾號。