Logic inside BuilderPattern

Question

Recentemente mi sono imbattuto in un modello di builder che mi ha incuriosito.

Quindi, ho uno EntityBuilder che crea un Entity, ma non restituisce l'entità. Qui è la firma del metodo:

public void build(); 

Invece, all'interno del metodo build(), si batte il nuovo oggetto creato, il Entity, a un'istanza CacheImplementation per memorizzarlo. Nota: il CacheImpl viene iniettato nel costruttore del costruttore.

public void build(){ 
    //create new entity 
    cacheImplementation.add(entity); 
} 

Questo suona come la migliore pratica?

Successivamente modificare 0

public interface EntityBuilder { 

    void setProperty0(PropertyObject propertyObject0); 
    void setProperty1(PropertyObject propertyObject1); 
    void setProperty2(PropertyObject propertyObject2); 
    //... 

    void build(); 
} 

public class EntityBuilderImpl implements EntityBuilder { 

    PropertyObject propertyObject0; 
    PropertyObject propertyObject1; 
    PropertyObject propertyObject2; 
    //... 

    // setters for all properties 
    @Override 
    public void build(){ 
     //create new entity 
     cacheImplementation.add(entity); 
    } 
} 

Il costruttore viene utilizzato nel modo seguente:

public class EntityProcessor{ 
    private EntityBuilderFactory entityBuilderFactory;//initialized in constructor 

    void process(EntityDetails entityDetails){ 
     EntityBuilder entityBuilder = this.entityBuilderFactory.getNewEntitytBuilder(); 
     //.. 
     // entityBuilder.set all properties from entityDetails 
     entityBuilder.build(); 
    } 
} 

Nota: l'istanza CacheImpl memorizza solo le entità in un List<> che è accessi ogni n secondi.

Answer 1

Questo suona come la migliore prassi?

Il modello di build tradizionale non memorizza l'oggetto creato da nessuna parte, semplicemente lo restituisce.

Posso immaginare una variante in cui il builder ha anche un ruolo di controllo dell'istanza per evitare la creazione di oggetti duplicati e la gestione di un archivio di oggetti immutabili.

La decisione di non restituire un'istanza potrebbe essere quella di chiarire che il metodo ha un effetto collaterale. Se il metodo restituisce l'oggetto, potrebbe essere fuorviante pensare che sia un costruttore tradizionale senza effetti collaterali, quando non è questo il caso.

In ogni caso, tutto questo è solo speculazione, in quanto non abbiamo visto il resto del codice in cui viene utilizzato e il modo in cui è implementato e utilizzato. Non abbiamo abbastanza contesto per giudicare veramente. Non c'è niente di sbagliato nell'inventare nuovi modelli, ma può essere fatto bene o male.

Answer 2

Ho visto il metodo void build() simile nella classe JCodeModel. Come si può vedere che getta IOException a causa del resources it manages:

public void build(File destDir, 
        PrintStream status) 
      throws IOException 

Fondamentalmente si chiede di svolgere l'operazione per voi e se nessun errore è presente - si può continuare con il flusso di lavoro.

Answer 3

Nel generatore generale viene utilizzato nel modo seguente: Alcune classi useranno il builder per creare la classe. Semplice

---

Ora avete ulteriore pezzo di complessità - caching. Puoi mettere il caching all'interno del Builder o di un livello più alto all'interno del Processore.

Quali sono le implicazioni di mettere la gestione della cache all'interno costruttore:

• Builder non ha più sola responsabilità.
• Non funziona come ci si aspetterebbe a prima vista
• Non si riesce a creare l'oggetto senza metterlo nella cache

Questi problemi non si verificano se si mette la gestione della cache di classe separata.

---

Direi che non è una soluzione terribile, ma sicuramente ridurrà la manutenibilità del codice.