Logik in BuilderPattern

Question

Kürzlich stieß ich auf ein Builder-Muster, das mich faszinierte.

Also habe ich eine EntityBuilder, die eine Entity erstellt, aber es gibt die Entität nicht zurück. Hier ist die Methodensignatur:

public void build(); 

stattdessen innerhalb der build() Methode liefert es das neue Objekt erstellt, das Entity, zu einer CacheImplementation Instanz zu speichern. Hinweis: CacheImpl wird in den Builder-Konstruktor eingefügt.

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

Hört sich das nach Best Practice an?

Später bearbeiten 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); 
    } 
} 

Der Builder in der folgenden Art und Weise verwendet wird:

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(); 
    } 
} 

Hinweis: Die CacheImpl Instanz speichert nur die Einheiten in einem List<>, die alle N Sekunden zugreift.

Answer 1

Hört sich das nach Best Practice an?

Das traditionelle Builder-Muster speichert das erstellte Objekt nicht irgendwo, es gibt es einfach zurück.

Ich kann mir eine Variante vorstellen, bei der der Builder auch die Rolle des Instanzsteuerelements übernimmt, um zu vermeiden, doppelte Objekte zu erstellen und ein Geschäft mit unveränderlichen Objekten zu verwalten.

Die Entscheidung, eine Instanz nicht zurückzugeben, könnte sein, um klarzustellen, dass die Methode einen Nebeneffekt hat. Wenn die Methode das Objekt zurückgibt, könnte es irreführend sein zu denken, dass es ein traditioneller Builder ohne Nebenwirkungen ist, wenn das hier nicht der Fall ist.

In jedem Fall ist dies alles nur Spekulation, da wir den Rest des Codes nicht gesehen haben, wo dies verwendet wird und wie es implementiert und verwendet wird. Wir haben nicht genug Kontext, um wirklich zu urteilen. Es ist nichts falsch daran, neue Muster zu erfinden, aber es kann gut oder schlecht gemacht werden.

Answer 2

Ich habe ähnliche void build() Methode in der JCodeModel Klasse gesehen. Wie Sie es, weil IOException sehen die resources it manages wirft:

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

Sie es im Grunde bitten, den Betrieb für Sie durchzuführen und wenn kein Fehler vorhanden ist - können Sie mit dem Workflow fortsetzen.

Answer 3

Im Allgemeinen wird Builder folgendermaßen verwendet: Einige Klassen verwenden Builder zum Erstellen von Klassen. Einfache

---

Jetzt haben Sie zusätzliches Stück Komplexität - Caching. Sie können Caching in Builder oder eine Ebene höher in Processor einfügen.

Was die Auswirkungen des Setzens Cache-Management innerhalb Builder sind:

• Builder haben keine einzige Verantwortung mehr.
• Es funktioniert nicht, wie man auf den ersten Blick
• Sie sind nicht in der Lage zu erwarten Objekt zu erstellen, ohne dass es in den Cache zu setzen

Diese Probleme werden nicht auftreten, wenn Sie Cache-Verwaltung auf eigene Klasse setzen.

---

Ich würde sagen, dass es keine schreckliche Lösung ist, aber es wird sicherlich die Wartbarkeit Ihres Codes verringern.