命名参数会替换生成器模式吗？

当使用支持命名和可选参数的语言时，构建器模式不再具有实际用途吗？

建造者：

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

可选/命名参数：

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

当您的对象需要大量的自变量/依赖性时，或者您希望允许使用许多不同的方式构造对象时，构建器将非常有用。

我可以想象，有人可能想在3D游戏中“构建”这样的对象：

// 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)
                          ...

我认为与使用可选参数相比，使用我刚刚构建的构建器方法更容易理解该示例：

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)
                    ...

特别是，构建器方法名称所隐含的信息必须替换为更多的参数，而忘记一组紧密相关的参数中的一个参数要容易得多。实际上，片段着色器丢失了，但是除非您知道要寻找它，否则您不会注意到这一点。

当然，如果您的对象仅需要一到五个参数来构造，则无论您是否具有命名/可选参数，都无需涉及到构建器模式。

除了Ixrec所说的以外，名为参数的构造函数或方法将不允许您将对象置于待构造状态，在构建状态下仍可以对其进行修改。这就是Builder的优点，您可以在其中将其构造的一部分委托给不同的方法或类：

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

inventoryManager.setPrices(myThingBuilder);

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

基本上，您还可以将构建器扔到系统上，直到准备构建最终对象为止，从而可以减少构建器-消费者需要具备的知识量。

这取决于您对构建器的处理方式。

如果仅使用构建器来设置（并改变）对象属性和（延迟）对象创建，则可以将其替换为命名参数。

替换构建器时，您可能具有@Ixrec改进的可读性/使用权衡（或者可能没有，这取决于您对构建器的操作）。

但是，如果您的构建器不仅仅是保留属性，而且每个构造步骤都涉及逻辑，则无法替换它。

MockBuilder是一个示例，其中不能将其替换为命名的params。从页面：

使用不可变对象时，构建器模式至关重要。使用不可变对象有很多好处，尤其是在并行环境（例如线程）中使程序更健壮地执行时