Java：Builder模式与逻辑分组对象

Question

我读了this question关于如何在java中拆分大型构造函数的问题。但我不太清楚在我的情况下我会做什么。问题表明，构建器模式是更好的方法，但与此同时，某个子句中的一个人说“只有某些参数是可选的”。因为我的所有参数都是强制性的，所以我看不到构建器模式的任何优点。我只冒险忘记传递重要的信息和平。因此，我唯一的选择是创建新的逻辑分组对象，还是我错过了构建器模式的一些重要事实？如果东西可以丢失，建筑商似乎只是好的？

Answer 1

“因此，我是创建新逻辑分组对象的唯一选择，还是我错过了构建器模式的一些重要事实？”

我的意见是：

是。与抽象中所需的工作量相比，在这种情况下使用构建器不会带来额外的好处。

评论中还提到：如果对象的参数太多，可能是对象做得太多了。

Answer 2

即使您的所有参数都是必需的，构建器模式仍然有一些优点：

1. 更具可读性。如果您的构造函数有十个参数，那很难 要记住哪个是哪个，特别是如果它们很多的话 0或null。

2. 构建器可以传递给几种不同的方法 积累所需的数据。如果某些数据，这很有用 存在于一个类中，一些存在于另一个类中。

3. 如果您的某些参数是需要的列表或其他集合 在被交给建设者之前组装，a 建设者可以在内部处理这个问题。他们也可以消除 因为建造者知道这一点，所以需要一些防御性副本 它不会泄漏任何这些物体。

4. 构建器可以充当序列化代理，为您提供更多代理 控制您的序列化表单或JAXB XML表单 对象

也就是说，我的方法总是从一个普通的构造函数开始，并且只有在调用该构造函数导致代码中出现大量混乱并且构建器添加的额外清晰度足以证明添加一个构造函数时才引入构建器。全新的课程。

Answer 3

构造函数的许多参数也可能是该类处理的太多关注点的标志。建筑工人只有在有级联案例时才有意义：对于男孩来说，为女孩添加一个粗鲁的语言部分是一个购物清单。

拆分问题取决于：继承，通用参数化类，委托类以及更重的逻辑分组对象。

还要考虑是否可以编写测试用例。测试驱动开发在这里很有帮助。如果您需要模拟参数类，“依赖注入”将需要更抽象的参数类。