3

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...

Community
  • 1
  • 1
lapsus
  • 2,915
  • 2
  • 32
  • 61
  • I'm thinking that the case for using a factory is going out of style these days. A programmer *could* utilize the factory pattern as well as DI, but why do that when you can do it all (including lazy instantiations) with DI alone? – code4life Feb 05 '15 at 20:45
  • A factory is usually useful when the creation process is complex and/or you want to relieve clients from knowing which concrete class they should be instantiating. E.g. `encryptionAlgorithmFactory.create({ prioritize: 'performance' });` In this case the client wants a fast algorithm, but doesn't have to know which concrete one to instanciate. – plalx Feb 05 '15 at 23:38

2 Answers2

2

(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.

Aasmund Eldhuset
  • 37,289
  • 4
  • 68
  • 81
  • +1, esp. regarding lazy loading/conditional instantiation. DI'ing the dependency kicks off the ctor, which (in badly designed apps) potentially gets heavy, leading to negative performance hits. Lazying these up is a good idea. You could also pass in a `Func` in the DI, though. Just a thought. – code4life Feb 05 '15 at 20:43
  • @code4life: True - but a `Func` is essentially a lightweight factory :-) – Aasmund Eldhuset Feb 05 '15 at 20:58
  • well, from one perspective, it's true. But wouldn't you agree that `Func` lets you meet impromptu necessities without all the formalities of a static typed class? – code4life Feb 05 '15 at 21:39
  • @code4life: Absolutely - hence, "lightweight" ;-) (but of course, that's far from the only usage of `Func`...) – Aasmund Eldhuset Feb 05 '15 at 21:40
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).

slvnperron
  • 1,323
  • 10
  • 13
  • Ok so you have a AbstractComputerFactory. And now you want to create an AbstractComputer - if your Person creates an AppleComputerFactory chances are you will never get the Lenovo you were hoping for. Don't implicitely decide (as the Person) which AbstractComputer I'll end up with? – lapsus Feb 06 '15 at 08:24
  • Yes, good point. That is where the `Provider` or `Store` comes in place. The `Person` shouldn't decide which type of `Factory` he will chose the `AbstractComputer` from. The `Provider` can sometimes be a real object, or sometimes the Dependency Injector plays that role. – slvnperron Feb 06 '15 at 10:48