建筑师设计模式的缺点
使用构建器设计模式的缺点是什么。 有没有？
编辑 – 我想知道使用构建器设计模式是否有任何不良后果？ 与GOF书中一样，他们提到了设计模式的好坏后果。 但他们没有提到建筑师设计模式的任何不良后果。
它确实在DTO中创建了比使用例如构造函数参数和/或setter / getter更多的代码（并且可能引入更多复杂性）。
在我看来，这不是什么大问题，在大多数情况下，没有太多的额外代码。 如果您的对象具有一些必需参数和一些可选参数，那么构建器模式将非常值得。
当图案被滥用/误用时，图案是不利的。 即模式根本没有解决/适合实际的技术/function问题。 然后，您应该寻找另一种模式来解决特定问题。
这并不特别适用于构建器模式，而是一般地设计模式。
更新 ：如果您有兴趣了解各种设计模式（特别是GoF设计模式书中提到的那些）和Java API中的真实世界示例，那么您可以找到答案： Java中的GoF设计模式示例核心库很有用。 它包含维基百科文章的链接，详细解释了模式。
我是第二个Jarle的post 。
否则，当遇到缺点时：
- 如果必须使用例如Hibernate或JAXB映射DTO，则构建器模式不是很好的匹配。
- 如果由于某些原因想要一个可变对象。
- 对于具有两个或三个字段的小型DTO，它只是开销，您应该使用一两个构造函数。 除非您知道/相信DTO将来会包含更多字段。
构建器模式，当与想法一起使用以克服Java中缺少可选参数时，您将丢失编译器提供的静态分析（以及IDE提供的所有良好的重构function）。 这意味着您将检测到某些必需参数仅在运行时丢失，而不是让您的IDE立即告诉您出现问题…
与望远镜构造器相比
- 失去静态分析
- 对于缺少必需参数，需要抛出exception并捕获一些exception
- 如果你在构建器中使用盒装类型来表示尚未设置的原始值，那么会有很多自动装箱/拆箱 – 这允许很难发现的NullPointerExceptions。 在望远镜构造函数中没有这样的问题 – 你可以传递原始值。
- 更多代码