So what signs indicate to you that you should consider a object factory of one sort or another?
Hmm, that's an interesting question. A good way to figure out when is to ask yourself what the consequences of using a factory are (ripped from GoF)
- "It isolates concrete classes": the client calling the factory only knows about the interface, not the implementation of the instantiated classes
- "It makes exchanging product families easy": self-explanatory
- "It promotes consistency among products": since they're so exchangeable, the developer is motivated to make them as consistent so that this exchange can actually happen
- "Supporting new kinds of products is difficult": if you have lots of factories, you'll have to modify a lot of code to add a new product
Note that there are varying strengths of factories. The above described is an "Abstract Factory", but you can also have a "Factory Method" which looks like this:
Prevents you from having to create an entirely new factory class but gives you a little less flexibility/interchangeability. Personally, I would see if this would work before going with a full-fledged factory object.
If one class instantiates another should you do it with a factory?
If you're a stickler about dependencies to interfaces not implementations, yes. Once again, however, it doesn't have to be an object factory, it can be a factory method.
Can you have factoryitis?
Yes. Use your good judgment. The golden rule of refactoring: the first time, just do it. The second time, do it but cringe. The third time, refactor!
Should you use a factory if the name of the class being instantiated is dynamically class
This is more reflection, so whether or not to use a factory is up to you. I would.