A Builder pattern is used for all implementations that return itself after setting something.
The following code was mass-produced for inserting using SimpleJdbcInsert.
new SimpleJdbcInsert(Jdbc template)
.Builder processing
.execute(new BeanPropertySqlParameterSource(Object to insert));
In this code, it is inefficient to new`` SimpleJdbcInsert and BeanPropertySqlParameterSource one by one, and there was a demand for efficiency in the entire project for other reasons, so efficiency is improved by wrapping the process with a function. I tried to figure it out.
Since the SimpleJdbcInsert is implemented in the Builder pattern, I could only think of an implementation by passing an initialized instance that implements the function.
However, this is almost not efficient at all.
Code that is not efficient at all
Wrap function(new SimpleJdbcInsert(Jdbc template).Builder processing,Object to insert);
I was able to implement it efficiently by writing it like a Fluent Builder pattern (loan pattern).
//Wrap function
public int insertExecute(UnaryOperator<SimpleJdbcInsert> builder, Object entity) {
return builder.apply(new SimpleJdbcInsert(Jdbc template))
.execute(new BeanPropertySqlParameterSource(entity));
}
//Usage example
insertExecute(it -> it.Builder processing,Object to insert);
It's a lack of study that the idea that "if the generation process by the builder is an obstacle, you should accept it" did not come up at once.
Builder pattern written in Java -Qiita
Recommended Posts