我读了这个关于如何在 java 中拆分大型构造函数的问题。但我不太确定在我的情况下我该怎么做。该问题表明构建器模式是更好的方法，但同时有人在某个子句中说“仅当某些参数是可选的”。因为我的所有参数都是强制性的，所以我看不到构建器模式的任何优势。我只会冒忘记传递重要信息的风险。因此，我是创建新的逻辑分组对象的唯一选择，还是我错过了构建器模式的一些重要事实？建设者似乎只有在可能缺少东西的情况下才好？
问问题
495 次
3 回答
2
“因此，我是创建新的逻辑分组对象的唯一选择，还是我错过了构建器模式的一些重要事实？”
我的意见是：
是的。与抽象所需的工作量相比，在这种情况下使用 builder 并没有带来额外的好处。
评论中还提到：如果一个对象的参数太多，则可能是该对象做的太多了。
于 2012-01-09T03:06:50.663 回答
0
即使您的所有参数都是必需的，构建器模式仍然具有一些优点：
它更具可读性。如果您的构造函数有十个参数，则很难记住哪个是哪个，尤其是当其中很多参数为 0 或 null 时。
构建器可以传递给几种不同的方法来积累它需要的数据。如果其中一些数据存在于一个类中而另一些存在于另一个类中，这将很有用。
如果您的某些参数是列表或其他集合，需要在传递给构造函数之前进行组装，生成器可以在内部处理这些问题。它们还可以消除对防御性副本的一些需求，因为构建器知道它不会泄漏任何这些对象。
构建器可以充当序列化代理，使您可以更好地控制对象的序列化形式或 JAXB XML 形式。
也就是说，我的方法总是从一个普通的构造函数开始，并且只有在调用该构造函数会在您的代码中造成很多混乱并且构建器添加的额外清晰度足以证明添加一个全新的类时才引入一个构建器.
于 2012-01-09T03:13:12.450 回答
0
构造函数的许多参数也可能表明该类正在处理太多问题。建设者只有在有级联案例时才有意义：为男孩添加粗鲁的语言部分，为女孩添加购物清单。
拆分关注点取决于：继承、通用参数化类、委托类，以及更重的逻辑分组对象。
还要考虑是否可以编写测试用例。测试驱动开发在这里很有帮助。如果您随后需要模拟参数类，“依赖注入”将需要更抽象的参数类。
于 2012-01-09T03:23:30.507 回答