Le modèle Builder comprend toutes les implémentations qui définissent quelque chose puis se renvoient.
Le code suivant a été produit en masse pour être inséré à l'aide de SimpleJdbcInsert.
new SimpleJdbcInsert(Modèle Jdbc)
.Traitement du constructeur
.execute(new BeanPropertySqlParameterSource(Objet à insérer));
Dans ce code, il est inefficace de nouveau SimpleJdbcInsertetBeanPropertySqlParameterSource` un par un, et il y avait une demande d'efficacité dans l'ensemble du projet pour d'autres raisons, donc l'efficacité est améliorée en enveloppant le processus avec une fonction. J'ai essayé de le comprendre.
Puisque le SimpleJdbcInsert est implémenté dans le modèle Builder, je ne pourrais penser à une implémentation qu'en passant une instance initialisée qui implémente la fonction.
Cependant, ce n'est presque pas efficace du tout.
Code qui n'est pas du tout efficace
Fonction Wrap(new SimpleJdbcInsert(Modèle Jdbc).Traitement du constructeur,Objet à insérer);
J'ai pu l'implémenter efficacement en l'écrivant comme un modèle Fluent Builder (modèle de prêt).
//Fonction Wrap
public int insertExecute(UnaryOperator<SimpleJdbcInsert> builder, Object entity) {
return builder.apply(new SimpleJdbcInsert(Modèle Jdbc))
.execute(new BeanPropertySqlParameterSource(entity));
}
//Exemple d'utilisation
insertExecute(it -> it.Traitement du constructeur,Objet à insérer);
C'est un manque d'étude que l'idée que "si le processus de génération par le constructeur est un obstacle, vous devez l'accepter" ne s'est pas posée tout de suite.
Modèle de générateur écrit en Java \ -Qiita
Recommended Posts