我阅读了这个问题,它涉及如何在Java中拆分大型构造函数。但是我不太确定在我的情况下该怎么做。该问题建议使用构建器模式是更好的选择,但同时有一个人在某个子句中说“只有一些参数是可选的”。因为我的所有参数都是必需的,我没有看到使用构建器模式的任何优势。我只会冒着忘记传递重要信息的风险。因此,我的唯一选择是创建新的逻辑分组对象,还是我对构建器模式缺少一些重要的事实?如果东西都不能缺少,那么构建器似乎没有用处?
我阅读了这个问题,它涉及如何在Java中拆分大型构造函数。但是我不太确定在我的情况下该怎么做。该问题建议使用构建器模式是更好的选择,但同时有一个人在某个子句中说“只有一些参数是可选的”。因为我的所有参数都是必需的,我没有看到使用构建器模式的任何优势。我只会冒着忘记传递重要信息的风险。因此,我的唯一选择是创建新的逻辑分组对象,还是我对构建器模式缺少一些重要的事实?如果东西都不能缺少,那么构建器似乎没有用处?
那么,我的唯一选择是创建新的逻辑分组对象吗?还是我在建造者模式上错过了一些重要的事实?
我的观点是:
是的。在这种情况下使用构建器与所需抽象化的工作量相比没有提供额外的好处。
评论中还提到:如果一个对象有太多参数,也许这个对象做了太多的事情。
它更易读。如果您的构造函数有十个参数,很难记住哪个是哪个,特别是如果其中许多参数为0或null。
建造者可以传递到几个不同的方法中,以累积所需的数据。如果某些数据存在于一个类中,而另一些数据存在于另一个类中,则这非常有用。
如果您的某些参数是需要在交付给构造函数之前进行组装的列表或其他集合,则建造者可以在内部处理它们。它们还可以消除某些防御性副本的需求,因为建造者知道它不会泄漏任何这些对象。
建造者可以作为序列化代理,为您提供更多对对象的序列化形式或JAXB XML形式的控制。
构造函数中的许多参数也可能是类处理过多关注点的迹象。仅当存在级联情况时,建造者才有意义:对于男孩添加粗鲁语言部分,对于女孩则是购物清单。
拆分关注点取决于继承、泛型参数化类、委托类,以及更重的逻辑分组对象。
还要考虑是否可以编写测试用例。在这里,测试驱动开发很有帮助。如果您需要模拟参数类,则“依赖注入”将需要更抽象的参数类。