17

使用构建器设计模式有什么缺点。有吗？？

编辑 - 我想知道使用构建器设计模式是否有任何不良后果？就像在 GOF 书中一样，他们提到了设计模式的好坏结果。但是他们没有提到构建器设计模式的任何不良后果。

4

5 回答 5

16

它确实在 DTO 中创建了更多的代码（并且可能引入更多的复杂性），而不是你有例如构造函数参数和/或设置器/获取器。

在我看来这没什么大不了的，在大多数情况下并没有太多额外的代码。如果您的对象具有一些强制性参数和一些可选参数，那么构建器模式将非常值得。

于 2010-05-13T18:04:52.893 回答
10

只有当模式被滥用/误用时，模式才是不利的。即该模式根本没有解决/适合实际的技术/功能问题。然后，您应该寻找另一种模式来解决特定问题。

这并不特别适用于构建器模式，而是一般的设计模式。

更新：如果您有兴趣了解各种设计模式（特别是 GoF 设计模式书中提到的那些）和 Java API 中的真实示例，那么您可能会找到这个答案：Java 中的 GoF 设计模式示例核心库 有用。它包含指向 Wikipedia 文章的链接，详细解释了这些模式。

于 2010-05-13T18:03:37.177 回答
4

我支持 Jarle 的帖子。

否则，当谈到缺点时：

  • 如果您必须使用 Hibernate 或 JAXB 映射 DTO，则构建器模式不是一个很好的匹配。
  • 如果您出于某些原因想要一个可变对象。
  • 对于具有两个或三个字段的小型 DTO，这只是开销，您应该使用一两个构造函数。除非您知道/相信 DTO 将来会包含更多字段。
于 2010-05-14T10:45:53.700 回答
4

构建器模式，当考虑到克服 Java 中缺少可选参数的想法时，您将失去编译器提供的静态分析（以及 IDE 提供的所有不错的重构功能）。这意味着您将仅在运行时检测到某些强制参数丢失，而不是让您的 IDE 立即告诉您有问题...

于 2012-06-11T21:32:38.200 回答
2

与望远镜构造器相比

  • 静态分析丢失
  • 对于缺少强制参数，需要在某处抛出和捕获异常
  • 如果您在构建器中使用装箱类型来表示尚未设置的原始值，那么会有很多自动装箱/拆箱 - 这允许很难发现 NullPointerExceptions。望远镜构造函数中没有这样的问题——你可以只传递原始值。
  • 更多代码
于 2015-10-06T13:50:06.873 回答