Factory pattern and my incapacity. Help me see the light

Question

Let's keep it simple...

class Client  
abstract class AbstractBusinessObject  
class BusinessObject  
class BusinessObjectFactory  

1. Okay, so your Client needs to perform some operations on AbstractBusinessObject . Obviously somewhere one BusinessObject instance needs to be created. Why not in the client? What's the harm?

2. Let's assume you convinced me to create new BusinessObjects in my BusinessObjectFactory. Great. Now the factory has to do the heavy lifting. Let's assume my factory has a Create(DataRow row) method because my BusinessObject needs the DataRow to extract useful information from it.
   My BusinessObject's properties are {get; private set;}. Therefore I cannot assign any property values in my factory. Probably I shouldn't anyway. This however means I have to pass along the DataRow entirely. So basically the factory just passes along my parameter. What's the use of the factory here?

3. Ok so I might have different implementation of BusinessObject - each of them having different constructors. I guess it makes sense for the factory to know how to construct any specific BusinessObject then. But then again I need a specific factory to get a specific BusinessObject. At least all examples I saw suggest just that. ConcreteFactoryB creates ConcreteProductB (ConcreteFactoryA creates ConcreteProductA) How does the client know how to construct the factory? Or even which one to create?

4. Ah the factory is injected... composition root. Right. But I could have injected the BusinessObject directly just as well.

5. The example over at DoFactory made it a little bit more clear I think. Is it all about making sure the Lion doesn't eat Bisons? And the Wolf doesn't feed on Wildebeests? If that's all the factory tries to assure I don't need one if I just want to create a single object, right?

So does a factory like this one here make any sense? Does a factory ever make sense if I only have one Create() method which only makes one type of classes?

Really, I read a lot about it. Every example looks like the other. I'm missing the point :( Can anyone provide a crystal clear real world example?

https://stackoverflow.com/a/2280289/1407618
Been there, done that...

Answer 1

(It looks like you accept the idea that dependency injection is (often) useful, so I'll base my answer on that assumption.)

If an instance of A depends on an instance of B, and you already have the B instance, then you should indeed inject it into the A instance without using a factory. However, factories are useful in these situations:

• Lazy loading: You don't have the B at the time you create the A, so A needs to create its own B (without knowing exactly what type B is, and possibly without knowing (all) of B's dependencies).
• Optional loading: In some situations, loading B might not even be necessary, and whether it is necessary or not must be determined by A.
• Multiple instances: A might need to create multiple instances of B whenever it wants to do so.

As usual, no pattern is a silver bullet, so there are many situations in which factories or dependency injection are overkill. Your questioning of the usefulness of factories is good, and will probably lead to you only using the pattern when it's actually beneficial.

Answer 2

You are a Person using an AbstractComputer. You do not care about the make of the computer, as long as it has all the basic stuff an AbstractComputer have. Now, in order to use a computer, would you Create() one yourself or would you get it from a ComputerStore or ComputerProvider? Those are going to give you the computer that best fits your needs (i.e. your budget, skills, screen size). They got their AbstractComputer shipped from a ComputerFactory that knows how to Create them best.

As for the properties of your AbstractComputer, some make it possible to swap the Storage and some don't. It really depends on your context. But for your factory to put them inside the computer, they needed an entry point (constructor) if they are not swappable after it is constructed.

The important point is that it is not the responsibility of the AbstractComputer to know how to constructs himself given the pieces. Nor it is the responsibility of the Consumer to know which make of computer it needs (they sometimes can, if they have enough knowledge and that their needs will never ever change).