Gli argomenti con nome sostituiscono il modello del builder?

I builder sono molto utili quando il tuo oggetto ha bisogno di un lotto di argomenti / dipendenze per essere utile, o vuoi consentire molti diversi modi di costruire l'oggetto.

In cima alla mia testa, posso immaginare che qualcuno possa voler "costruire" oggetti in un gioco 3D come questo:

// Just ignore the fact that this hypothetical god class is coupled to everything ever
new ObjectBuilder(x, y, z).importBlenderMesh("./meshes/foo")
                          .syncWithOtherPlayers(serverIP)
                          .compileShaders("./shaders/foo.vert", "./shaders/foo.frag")
                          .makeDestructibleRigidBody(health, weight)
                          ...

Direi che questo esempio è più leggibile con i metodi builder creati in questo momento rispetto ai parametri facoltativi:

new Object(x, y, z, meshType: MESH.BLENDER,
                    meshPath: "./meshes/foo",
                    serverToSyncWith: serverIP,
                    vertexShader: "./shaders/foo.vert",
                    physicsType: PHYSICS_ENGINE.RIGID_DESTRUCTIBLE,
                    health: health,
                    weight: weight)
                    ...

In particolare, le informazioni implicite dai nomi dei metodi builder devono essere sostituite da altri parametri, ed è molto più facile dimenticare un parametro in un gruppo di parametri strettamente correlati. In effetti, lo shader di frammenti manca, ma non lo si noterebbe a meno che non si sapesse di cercarlo.

Naturalmente, se il tuo oggetto richiede solo da uno a cinque argomenti da costruire, non c'è bisogno di coinvolgere il modello di builder, indipendentemente dal fatto che tu abbia o meno dei parametri denominati / facoltativi.

Oltre a quanto detto da Ixrec, i costruttori o il metodo chiamato parametri non ti permetteranno di avere il tuo oggetto in uno stato da costruire in cui può ancora essere modificato prima di costruirlo. Questa è la bellezza del Builder, dove puoi delegare parti della sua costruzione a diversi metodi o classi altgether:

var myThingBuilder = new ThingBuilder("table");
myThingBuilder.setAttribute(Attributes.Legs, 4);

inventoryManager.setPrices(myThingBuilder);

// inventory manager
var availableCheapestMaterial = getMaterial();
myThingBuilder.setMaterial(availableCheapestMaterial);

Fondamentalmente, puoi anche lanciare il builder attorno al tuo sistema fino a quando non è pronto a costruire l'oggetto finale, permettendoti di ridurre la quantità di conoscenza che il tuo builder-consumatore deve avere.

Dipende da cosa stai facendo con il costruttore.

Se si sta usando il builder solo per impostare (e variare) le proprietà dell'oggetto e la (differita) creazione dell'oggetto, può essere sostituito con parametri nominati.

Sostituendo il builder potresti avere il compromesso di leggibilità / utilizzo che @Ixrec ha menzionato (o potrebbe non averlo, dipende da cosa stai facendo con il builder).

Tuttavia, se il tuo costruttore fa molto più che tenere le proprietà e ogni fase di costruzione implica la logica, non può essere sostituito.

MockBuilder è un esempio in cui non può essere sostituito con param nominati. Dalla pagina:

Il modello di builder è essenziale quando si lavora con oggetti immutabili. Ci sono molti vantaggi nel lavorare con oggetti immutabili, specialmente nel fare in modo che il tuo programma sia più robusto in esecuzione in un ambiente concorrente (cioè thread)