Java：构建模式与逻辑分组对象

Question

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

Answer 1

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

是的。在这种情况下使用构建器与抽象中所需的工作量相比没有提供额外的好处。

也在评论中提到：如果你有太多的对象参数，可能对象是做得太多。

Answer 2

即使所有的参数都是强制性的，建造者模式还是有一些优势：

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

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

3. 如果你的一些参数是列表或需要 越区切换到构造前组装其他集合，一个 建设者可以在内部照顾那个。他们还可以消除一些防御性副本的需求，因为构建者知道它不会泄漏任何这些对象。

4. 构建器可以作为序列化代理，使您可以更多地控制 对象的序列化表单或JAXB XML表单。

这就是说，我的做法将永远是一个普通的构造函数开始，并介绍只有当调用该构造函数是造成一大堆乱七八糟的代码，并由制造商增加了额外的清晰度足够建设者证明增加一个全新的课程是合理的。

Answer 3

构造函数的许多参数也可能是类正在处理的太多问题的迹象。有级联的情况下，建设者才有意义：对于男孩而言，为女孩添加粗俗语言部分是一个购物清单。

拆分问题取决于：继承，泛型参数化类，委托类和是较重的逻辑分组对象。

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