Java Spring
    项目引用了一个依赖jar，配置封装太封闭了，不能扩展。业务变动一次那个jar就要跟着升级一次，而且不同的项目还引用了这个jar的不同版本。所以通过可扩展定制化实现可以很好的提高效率。
    原本的配置类似是这样的：

    1. @Configuration(proxyBeanMethods = false)
    2. public class MyConfiguration {
    4.     /**
    5.      * bean
    6.      */
    7.     @Bean
    8.     ConfigBean configBean(Config config)  {
    9.         //todo 逻辑
    10.      return new ConfigBean(config)
    11.     }     
    12. }

    如果想根据项目的不同定制不同的ConfigBean就不太好弄了。如果能在Config对象传入ConfigBean构造之前放一个修改Config的口子就好了。这样ConfigBean的初始化生命周期也变成了 :::info 发现Config对象-> 修改Config对象-> 初始化ConfigBean ::: 于是定义了一个可以修改Config对象的接口：

    1. @FunctionalInterface
    2. public interface ConfigCustomizer {
    4.     /**
    5.      * Customize.
    6.      *
    7.      * @param config the config
    8.      */
    9.     void customize(Config config);
    10. }

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

    1. @Configuration(proxyBeanMethods = false)
    2. public class MyConfiguration {
    3.     private List<ConfigCustomizer> configCustomizers = Collections.emptyList();
    4.     /**
    5.      * bean
    6.      */
    7.     @Bean
    8.     ConfigBean configBean(Config config)  {
    10.         // 其它公共逻辑省略
    12.         // 最后定制逻辑注入
    13.         configCustomizers
    14.                 .forEach(configCustomizer -> configCustomizer.customize(config));
    15.      return new ConfigBean(config)
    16.     }
    18.     @Autowired(required = false)
    19.     void setConfigCustomizers(List<ConfigCustomizer> configCustomizers) {
    20.         this.configCustomizers = configCustomizers;
    21.     }
    22. }

    这样需要改动配置时只需要声明一个ConfigCustomizerBean即可，它会被setConfigCustomizers自动发现并执行自定义的方法。
    这里会有朋友说@ConditionalOnMissingBean系列注解也能干这个事啊，没错！这样完全可以声明一个新的ConfigBean取而代之。但是这是两种策略：一种是修修补补就能用；一种是推倒重来。在封装组件的时候要合理利用这些策略，该开口子的要开口子，不该开放的保持封闭，另外保证组件的扩展性也是很重要的。