Alle Implementierungen, die etwas festlegen und sich dann selbst zurückgeben, sind die Builder-Muster.
Der folgende Code wurde in Massenproduktion zum Einfügen mit "SimpleJdbcInsert" erstellt.
new SimpleJdbcInsert(JDBC-Vorlage)
.Builder-Verarbeitung
.execute(new BeanPropertySqlParameterSource(Objekt zum Einfügen));
In diesem Code ist es ineffizient, "new" "SimpleJdbcInsert" und "BeanPropertySqlParameterSource" nacheinander zu verwenden, und aus anderen Gründen bestand im gesamten Projekt ein Bedarf an Effizienz, sodass die Effizienz durch Umschließen des Prozesses mit einer Funktion verbessert wird. Ich habe versucht, es herauszufinden.
Da das "SimpleJdbcInsert" im "Builder" -Muster implementiert ist, konnte ich mir eine Implementierung nur vorstellen, indem ich eine initialisierte Instanz übergab, die die Funktion implementiert. Dies ist jedoch fast überhaupt nicht effizient.
Code, der überhaupt nicht effizient ist
Wrap-Funktion(new SimpleJdbcInsert(JDBC-Vorlage).Builder-Verarbeitung,Objekt zum Einfügen);
Ich konnte es effizient implementieren, indem ich es wie ein Fluent Builder-Muster (Kreditmuster) schrieb.
//Wrap-Funktion
public int insertExecute(UnaryOperator<SimpleJdbcInsert> builder, Object entity) {
return builder.apply(new SimpleJdbcInsert(JDBC-Vorlage))
.execute(new BeanPropertySqlParameterSource(entity));
}
//Anwendungsbeispiel
insertExecute(it -> it.Builder-Verarbeitung,Objekt zum Einfügen);
Es ist ein Mangel an Studien, dass die Idee, dass "wenn der Generierungsprozess durch den Bauherrn ein Hindernis ist, sollten Sie es akzeptieren", nicht sofort aufkam.
In Java \ -Qiita geschriebenes Builder-Muster
Recommended Posts