在一个工厂的构造函数中有太多的params代码味道?

时间:2011-03-09 21:40:26

标签: java design-patterns

我有一个工厂类,目前在它的构造函数中需要6个参数,我只需要添加另一个。

通常情况下,这会让我尖叫“嘿,你的班级有太多的依赖关系,因此,它确实太多了!”

但是,考虑到这个班级是严格的工厂,那是不是真的如此?我应该关注越来越多的依赖关系吗?如果是这样,我应该考虑采取什么策略进行重构呢?

更新
我曾经考虑过建造者模式,但对于工厂来说,这不是太过分了吗?

(即WidgetFactoryBuilder,它构建了一个构建小部件的工厂。)。

此外,我不明白构建器如何真正减轻我的依赖关系 - 它只是将它们从构造函数移动到方法 - 这似乎使事情变得更加模糊 - 但是这可能归结为对如何应用的理解不足在这种情况下的构建器模式。

3 个答案:

答案 0 :(得分:11)

  • 考虑将您的参数(无论什么有意义)分组到某种类型的FactoryConfigurationObject中
  • 如果失败,请考虑使用Builder模式
  • 但一般都是,3个参数开始闻到......

答案 1 :(得分:7)

首先,我要提一下,我不一定认为六个参数太多了。但如果你坚持......

我认为问题根本不在于构造函数的参数数量。

其他人推荐的构建器模式对包含大量状态的类很有用。对于工厂来说,这种情况很少发生。我会假设你所讨论的参数是对其他类的依赖。真正的问题是你的工厂有太多的依赖 - 而不是它的构造函数需要太多的参数。

相反,你需要看看设计。为什么工厂有这么多的依赖?有可能以某种方式减少这个数字吗?也许工厂创建的对象本身太复杂了?

答案 2 :(得分:1)

当许多参数是可选的时,这尤其是个问题。在这种情况下,consider the Builder Pattern

另外,请考虑您的构造函数是否确实需要您提供的每个特定类。例如,如果它需要URL,则传递URL,而不是恰好具有WebPage属性的URL对象。这不会减少参数的数量,但会限制外部依赖的表面积。

关于您的更新:我和@ iluxa的回复主要集中在具有多个参数的方法的另一个缺点,即它们难以阅读和维护。在此上下文中,Builder是工厂的替代。见this answer

依赖性问题只能通过另一个问题来回答:您的工厂真正依赖于每个参数吗?试着想一想它可能没有的方式。