java 建造者设计模式的缺点
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/2829106/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
disadvantages of builder design pattern
提问by agrawalankur
What would be the disadvantages of using the builder design pattern. Are there any??
使用构建器设计模式的缺点是什么。有吗？？
edit - I want to know whether there is any bad consequence of using builder design pattern? As in the GOF book, they have mentioned the good and bad consequences of design patterns. But they haven't mentioned any bad consequence for builder design pattern.
编辑 - 我想知道使用构建器设计模式是否有任何不良后果？就像在 GOF 书中一样，他们提到了设计模式的好坏后果。但是他们没有提到构建器设计模式的任何不良后果。
采纳答案by Jarle Hansen
It does create more code (and could introduce more complexity) in the DTO than if you had for example contructor arguments and/or setters/getters.
它确实在 DTO 中创建了更多的代码（并且可能会引入更多的复杂性），而不是你有例如构造函数参数和/或 setter/getter。
In my opinion this is not a big deal, in most cases there is not a lot of extra code. The builder pattern will be more than worth it if you have an object that has some mandatory and some optional parameters.
在我看来这没什么大不了的，在大多数情况下，没有很多额外的代码。如果您的对象具有一些必需参数和一些可选参数，那么构建器模式将非常值得。
回答by BalusC
A pattern is only disadvantageous when the pattern is been abused/misused. I.e. the pattern didn't solve/suit the actual technical/functional problem at all. You should then to look for another pattern to solve the particular problem.
只有当模式被滥用/误用时，模式才是不利的。即模式根本没有解决/适合实际的技术/功能问题。然后，您应该寻找另一种模式来解决特定问题。
This doesn't specifically apply to the builder pattern, but to design patterns in general.
这并不特别适用于构建器模式，而是适用于一般的设计模式。
Update: if you'd be interested to learn about the various design patters (specifically the ones mentioned in the GoF Design Patterns book) and the real world examples in Java API, then you may find this answer: Examples of GoF Design Patterns in Java's core librariesuseful. It contains links to Wikipedia articles explaining the patterns in detail.
更新：如果您有兴趣了解各种设计模式（特别是 GoF 设计模式书中提到的那些）和 Java API 中的真实世界示例，那么您可能会找到这个答案：Java 中的 GoF 设计模式示例核心库很有用。它包含指向详细解释模式的 Wikipedia 文章的链接。
回答by Espen
I second Jarle's post.
我支持 Jarle 的帖子。
Else, when it comes to disadvantages:
否则，当谈到缺点时：
- The builder pattern isn't a good match if you have to map the DTO with for example Hibernate or JAXB.
- If you for some reasons want a mutable object.
- For small DTOs with two or three fields, it's just overhead and you should rather use a constructor or two. Unless you know/believe the DTO will contain more fields in the future.
- 如果您必须将 DTO 与 Hibernate 或 JAXB 等进行映射，则构建器模式不是很好的匹配。
- 如果您出于某些原因想要一个可变对象。
- 对于具有两个或三个字段的小型 DTO，这只是开销，您应该使用一两个构造函数。除非您知道/相信 DTO 将来会包含更多字段。
回答by Francois Misiak
Builder pattern, when used with the idea in mind to overcome the lack of optional parameters in Java, you lose the static analysis provided by the compiler (and all the nice refactoring features provided by your IDE). This means that you'll detect that some mandatory parameters are missing only at runtime, instead of having your IDE telling you immediately that something is wrong...
构建器模式，当考虑到克服 Java 中缺少可选参数的想法时，您将失去编译器提供的静态分析（以及您的 IDE 提供的所有漂亮的重构功能）。这意味着您只会在运行时检测到某些强制性参数丢失，而不是让您的 IDE 立即告诉您出现问题...
回答by Alex
comparing to telescope constructors
与望远镜建造者相比
- loss of static analysis
- for missing mandatory parameters an exception needs to be thrown and catched somethere
- if you use boxed types in builders to represent primitive values which are not set yet, then there is a lot of auto-boxing/unboxing going on - which allows for NullPointerExceptions which are hard to spot. No such problem in telescope constructors - you can just pass primitive values.
- a lot more code
- 静态分析损失
- 对于缺少必需参数，需要在那里抛出并捕获异常
- 如果您在构建器中使用装箱类型来表示尚未设置的原始值，那么会有很多自动装箱/拆箱正在进行 - 这允许难以发现的 NullPointerExceptions。望远镜构造函数中没有这样的问题——你可以只传递原始值。
- 更多的代码
