Gli argomenti con nome sostituiscono il modello di generatore?

Quando si utilizza un linguaggio che supporta argomenti con nome e facoltativi, il modello del builder non ha più un uso pratico?

Costruttore:

new Builder(requiredA, requiredB).setOptionalA("optional").Build();

Argomenti opzionali / nominati:

new Object(requiredA, requiredB, optionalA: "optional");

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

Dalla parte superiore della mia testa, posso immaginare che qualcuno potrebbe 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 che ho inventato proprio ora che con i parametri opzionali:

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 del builder devono essere sostituite da ancora più parametri, ed è molto più facile dimenticare un parametro in un gruppo di parametri strettamente correlati. In realtà, lo shader di frammenti manca, ma non lo noteresti a meno che non sapessi cercarlo.

Naturalmente, se il tuo oggetto richiede solo da uno a cinque argomenti per la costruzione, non è necessario coinvolgere il modello di builder, indipendentemente dal fatto che tu abbia o meno dei parametri nominati / opzionali.

Oltre a ciò che ha detto 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, in cui puoi delegare parti della sua costruzione a diversi metodi o classi contemporaneamente:

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

inventoryManager.setPrices(myThingBuilder);

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

Fondamentalmente, sei anche in grado di gettare il tuo costruttore nel tuo sistema fino a quando non è pronto per costruire l'oggetto finale, permettendoti di ridurre la quantità di conoscenza che il tuo costruttore-consumatore deve avere.

Dipende da cosa stai facendo con il costruttore.

Se si utilizza il builder solo per impostare (e variare) le proprietà degli oggetti e (differire) la creazione degli oggetti, è possibile sostituirli con parametri nominati.

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

Tuttavia, se il tuo costruttore non si limita a mantenere le proprietà e ogni passaggio di costruzione implica la logica, non può essere sostituito.

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

Il modello del generatore è essenziale quando si lavora con oggetti immutabili. Ci sono molti vantaggi nel lavorare con oggetti immutabili, specialmente nel rendere il tuo programma più robusto eseguendolo in un ambiente concorrente (es. Thread)