9

I have a factory class that currently takes 6 params in it's constructor, and I just hit a need to add another.

Normally, this would scream to me "Hey, your class has too many dependencies, therefore, it does too much!"

However, given this class is strictly a factory, is that really the case? Should I be concerned about the growing number of dependencies? If so, what strategies should I consider for refactoring this?

Update:
I had considered the builder pattern, but for a factory, isn't that overkill?

(Ie., WidgetFactoryBuilder, which builds a factory which builds widgets.).

Additionally, I don't understand how a builder really alleviates my dependencies - it just moves them from the constructor to methods -- which seems to obfuscate things more -- however this could be down to a poor understanding of how to apply the builder pattern in this situation.

Bhargav Rao
  • 50,140
  • 28
  • 121
  • 140
Marty Pitt
  • 28,822
  • 36
  • 122
  • 195
  • What does exactly code-smell means ? First time i hear about it – Carlos Valenzuela Mar 09 '11 at 21:51
  • 1
    @Chuck Code Smells are a indication that there's something wrong with your code. I'm not sure if it was coined by Bob Martin, but it was in his books that I first read about it. http://en.wikipedia.org/wiki/Code_smell – Marty Pitt Mar 09 '11 at 21:53
  • 1
    @Chuck Birkin, A code smell is basically when a piece of code doesn't explicitly contain bugs but could be considered an indicator that the application was poorly designed/pieced together and therefore likely contains bugs. http://en.wikipedia.org/wiki/Code_smell – Tim Bender Mar 09 '11 at 21:56
  • Pitt, @Tim Bender Thanks guys – Carlos Valenzuela Mar 09 '11 at 22:23
  • 2
    Kent Beck coined the "code smell" term. He created extreme programming while at Chrysler. Big Time refactoring and TDD author etc.. – Tom Stickel Dec 13 '11 at 00:05
  • Too many related primitive parameters often represent a code smell called "Primitive obsession". You should consider combining them into a Class. Too many unrelated domain object parameter suggest that your class or object is doing too much. Consider breaking its repsonsibilities. – Code Name Jack Jun 15 '20 at 09:23

3 Answers3

11
  • consider grouping your parameters (whatever makes sense) into FactoryConfigurationObject of some kind
  • if that fails, consider using Builder pattern
  • but generally yes, above 3 parameters begins to smell...
iluxa
  • 6,941
  • 18
  • 36
  • I'm not sure that the builder pattern is a good fit, as my class is a factory. Maybe this is my poor understanding -- would you mind expanding how you would use a builder here? – Marty Pitt Mar 09 '11 at 22:13
  • 1
    Factory f = new Factory.Builder().withParam1().withParam2().withParam3().create(); – iluxa Mar 09 '11 at 23:18
  • +1 Grea reply about the context object! – Nilesh Mar 10 '11 at 03:18
  • "above 3 parameters begins to smell" 3 is way too low a number for assuming a smell. Especially in a factory – James Feb 21 '22 at 12:55
7

First of all, I should mention that I don't necessarily think six parameters are too many. But if you insist...

I don't think the problem at all lies in the number of parameters to the constructor.

The builder pattern that others recommend is useful for classes that contain a lot of state. This is rarely the case for a factory. I am instead going to assume that the parameters you are talking about are dependencies on other classes. The real problem is that your factory has too many dependencies - not that its constructor takes too many arguments.

Instead you need to look at design. Why does the factory have so many dependencies? Is it possible to reduce that number somehow? Maybe the objects that the factory creates are themselves too complex?

waxwing
  • 18,547
  • 8
  • 66
  • 82
  • What do you do when you have a complex object by nature? Like say 8 properties and 5 of them are themselves another object? – James Feb 21 '22 at 12:56
1

This is especially a problem when many of the parameters are optional. In such cases, consider the Builder Pattern.

Also, consider whether your constructor really needs each of the specific classes you're providing. For example, if it needs a URL, then pass it a URL, not a WebPage object that happens to have a URL property. This won't reduce the number of parameters, but it will limit the surface area of external dependencies.

Regarding your update: Mine and @iluxa's responses focus largely on another downside of methods with multiple params, which is that they are hard to read and maintain. The Builder in this context is an alternative to your Factory. See this answer.

The dependency issue can only be answered with another question: does your Factory truly depend on every param? Try to think of ways in which it might not.

Community
  • 1
  • 1
Wayne
  • 59,728
  • 15
  • 131
  • 126