头部首次设计模式仅简短地描述了 附录中的构建器模式，而没有将其与其他模式相比，而没有专门的空间。
就像其他设计模式一样对待它。
重构guru 也将建筑商的模式视为“真”模式，而无需将其降级到附录。
无论如何，我认为，第一个和第三个来源的重点是该模式如何用客户所需的“成分”构造对象是如何有用的。
换句话说，一个不好的解决方案将拥有这样的构造函数
Ctor::Ctor(Param1* param1, Param2* param2, Param3* param3 /*, and many more */);
，必须由不想设置前两个参数的客户来调用这样的构造函数，
auto obj = Ctor(null, null, some_param3 /*, null, null */);
而构建器模式将允许一个人构建这样的对象：
auto obj = Builder().setParam3(some_param3).build();
但是，如果解决所有构建器模式是上述问题，那么我会觉得命名参数将提供相同的解决方案（，我不是唯一想知道的人）。反过来，我将“构建器模式”称为“命名参数模式”，它可以指导您以缺乏它的语言来实现此功能。
确实，网络上有一些声称其他语言不需要这种模式的消息来源（或者，如果您愿意，该模式在它们中的可见程度较低）：
- 在这里令人信服的例子，说明了Clojure的破坏性力量如何仅仅给出您只需要传递您想要的参数而需要的所有内容，而您只想传递您想要的构造函数；
- Facebook的研究工程师（至少在他撰写此内容时），主张 haskell的类型类别和智能构建器就是所有需要继续没有建造者模式，即使他对这个话题没有任何深度。
因此，鉴于上述点1，我的问题是构建器模式是否真的提供了诸如命名参数之类的语言功能。
（我不确定我已经理解了第2个问题。）
Head First Design Patterns only briefly describes the builder pattern in the appendix, without dedicating to it as much space as to other patterns.
Design Patterns: Elements of Reusable Object-Oriented Software treats it just like other design patterns.
Refactoring Guru also considers the builder pattern as a "true" pattern, without relegating it to an appendix.
Anyway, the first and the third sources put a strong focus, in my opinion, on how the pattern is useful to construct an object with just as many "ingredients" as the client wants.
In other words, a bad solution would be having a constructor like this
Ctor::Ctor(Param1* param1, Param2* param2, Param3* param3 /*, and many more */);
that needs to be called like this by a client who doesn't want to set the first two parameters
auto obj = Ctor(null, null, some_param3 /*, null, null */);
whereas the builder pattern would allow one to construct an object like this:
auto obj = Builder().setParam3(some_param3).build();
However, if all the builder pattern solved was the problem above, then I'd feel like named parameters would offer the same solution (and I'm not the only one to wonder about it). In turn, I'd have called the "builder pattern" the "named parameters pattern", that guides you to implement this feature in a language that lacks it.
Indeed, there are sources on the web that claim other languages don't need this pattern (or, if you like, the pattern is just less visible in them):
- here a convincing example of how Clojure's destructuring power just gives all you need as regards passing only the arguments you want to a constructor;
- a research engineer at Facebook (at least at the time he wrote this stuff), claims that Haskell's type classes and smart constructor are all you need to go on without the builder pattern, even though he doesn't go into any depth on the topic.
So, in view of the above point 1, my question is whether the builder pattern really offers more than a language feature like named parameters.
(I'm leaving point 2 out of the question because I'm not sure I've understood it.)
发布评论
评论（1）
构建器模式是某些语言允许的可选命名构造参数的可靠替代品，甚至是经常在打字稿或类似文章中使用的强烈键入的“道具”文字。
与这些其他方法相比，它有两个重要的问题：
您必须编写一个建筑商类 - 许多代码重复您在构建的班级中已经写过的内容；和
The builder pattern is a poor substitute for the optional named constructor parameters that some languages allow, or even the strongly typed "Props" literals that are often used in Typescript or similar.
There are two significant problems with it, compared to these other approaches:
You have to write a builder class -- a lot of code that repeats things you already wrote in the class you're building; and
There is no reasonable way to make the required parameters required.