Sunday, March 30, 2014

The Builder pattern and the Spring framework

Introduction

 

I like to make use of the builder pattern whenever an object has both mandatory and optional properties. But building objects is usually the Spring framework responsibility, so let’s see how you can employ it using both Java and XML-based Spring configurations.

A Builder example

 

Let’s start from the following Builder class.

01public final class Configuration<T extends DataSource> extends ConfigurationProperties<T, Metrics, PoolAdapter<T>> {
02
03    public static final long DEFAULT_METRIC_LOG_REPORTER_PERIOD = 5;
04
05    public static class Builder<T extends DataSource> {
06        private final String uniqueName;
07        private final T targetDataSource;
08        private final PoolAdapterBuilder<T> poolAdapterBuilder;
09        private final MetricsBuilder metricsBuilder;
10        private boolean jmxEnabled = true;
11        private long metricLogReporterPeriod = DEFAULT_METRIC_LOG_REPORTER_PERIOD;
12
13        public Builder(String uniqueName, T targetDataSource, MetricsBuilder metricsBuilder, PoolAdapterBuilder<T> poolAdapterBuilder) {
14            this.uniqueName = uniqueName;
15            this.targetDataSource = targetDataSource;
16            this.metricsBuilder = metricsBuilder;
17            this.poolAdapterBuilder = poolAdapterBuilder;
18        }
19
20        public Builder setJmxEnabled(boolean enableJmx) {
21            this.jmxEnabled = enableJmx;
22            return this;
23        }
24
25        public Builder setMetricLogReporterPeriod(long metricLogReporterPeriod) {
26            this.metricLogReporterPeriod = metricLogReporterPeriod;
27            return this;
28        }
29
30        public Configuration<T> build() {
31            Configuration<T> configuration = new Configuration<T>(uniqueName, targetDataSource);
32            configuration.setJmxEnabled(jmxEnabled);
33            configuration.setMetricLogReporterPeriod(metricLogReporterPeriod);
34            configuration.metrics = metricsBuilder.build(configuration);
35            configuration.poolAdapter = poolAdapterBuilder.build(configuration);
36            return configuration;
37        }
38    }
39
40    private final T targetDataSource;
41    private Metrics metrics;
42    private PoolAdapter poolAdapter;
43
44    private Configuration(String uniqueName, T targetDataSource) {
45        super(uniqueName);
46        this.targetDataSource = targetDataSource;
47    }
48
49    public T getTargetDataSource() {
50        return targetDataSource;
51    }
52
53    public Metrics getMetrics() {
54        return metrics;
55    }
56
57    public PoolAdapter<T> getPoolAdapter() {
58        return poolAdapter;
59    }
60}

 

Java-based configuration

 

If you’re using Spring Java-based configuration then this is how you’d do it:

01@org.springframework.context.annotation.Configuration
02public class FlexyDataSourceConfiguration {
03
04    @Autowired
05    private PoolingDataSource poolingDataSource;
06
07    @Bean
08    public Configuration configuration() {
09        return new Configuration.Builder(
10                UUID.randomUUID().toString(),
11                poolingDataSource,
12                CodahaleMetrics.BUILDER,
13                BitronixPoolAdapter.BUILDER
14        ).build();
15    }
16
17    @Bean(initMethod = "start", destroyMethod = "stop")
18    public FlexyPoolDataSource dataSource() {
19        Configuration configuration = configuration();
20        return new FlexyPoolDataSource(configuration,
21                new IncrementPoolOnTimeoutConnectionAcquiringStrategy.Builder(5),
22                new RetryConnectionAcquiringStrategy.Builder(2)
23        );
24    }
25}

 

XML-based configuration

 

The XML-based configuration is more verbose and not as intuitive as the Java-based configuration:

01<bean id="configurationBuilder" class="com.vladmihalcea.flexypool.config.Configuration$Builder">
02    <constructor-arg value="uniqueId"/>
03    <constructor-arg ref="poolingDataSource"/>
04    <constructor-arg value="#{ T(com.vladmihalcea.flexypool.metric.codahale.CodahaleMetrics).BUILDER }"/>
05    <constructor-arg value="#{ T(com.vladmihalcea.flexypool.adaptor.BitronixPoolAdapter).BUILDER }"/>
06</bean>
07
08<bean id="configuration" factory-bean="configurationBuilder" factory-method="build"/>
09
10<bean id="dataSource" class="com.vladmihalcea.flexypool.FlexyPoolDataSource" init-method="start" destroy-method="stop">
11    <constructor-arg ref="configuration"/>
12    <constructor-arg>
13        <array>
14            <bean class="com.vladmihalcea.flexypool.strategy.IncrementPoolOnTimeoutConnectionAcquiringStrategy$Builder">
15                <constructor-arg value="5"/>
16            </bean>
17            <bean class="com.vladmihalcea.flexypool.strategy.RetryConnectionAcquiringStrategy$Builder">
18                <constructor-arg value="2"/>
19            </bean>
20        </array>
21    </constructor-arg>
22</bean>

 

Conclusion

 

You can make use of the Builder pattern no matter the Spring configuration mode you’ve already chosen. If you have doubts about it’s usefulness, here are three compelling reasons you should be aware of.

Reference: The Builder pattern and the Spring framework from our JCG partner Vlad Mihalcea at the Vlad Mihalcea’s Blog blog.

1 comment: