myth about factory pattern

Question

This has bothered me for awhile, and I have no clues if this is a myth.

It seems that a factory pattern can ease the pain of adding a dependency for a class.

For example, in a book, it has something like this

Suppose that you have a class named Order. Initially it did not depend on anything. Therefore you didn't bother using a factory to create Order objects and you just used plain new to instantiate the objects. However, you now have a requirement that Order has to be created in association with a Customer. There are million places you need to change to add this extra parameter. If only you had defined a factory for the Order class, you would have met the new requirement without the same pain.

How is this not same pain as adding an extra parameter to the constructor? I mean you would still need to provide an extra argument for the factory and that is also used by million places, right?

Answer 1

If the user is known only at the time, the order is created, you could implement a getCurrentUser() function that is called by the factory.
If that is possible, the factory function obviously wins. If not, then there is no gain.

If, in the past, you didn't know there would ba a customer needed, you probably also could not know whether it's possible to implement a getCurrentUser() function. The chances of the factory method paying off may not be very good but they don't always equal 0.

Answer 2

The real benefit to using a Factory is that it is a façade which hides just how you go about creating an object that fulfills the Order role. To be more exact, the Factory knows that you're really making a FooBarOrder, and nothing else has to be changed to switch from always making a FooBarOrder to sometimes making a BarFooOrder instead. (If Java let you intercept new and make a subclass instead, there would be no need for Factories. But it doesn't – fairly reasonably, to be fair – so you have to have them. Object systems which allow subclassing the class of classes are more flexible in this regard.)

Answer 3

No, because the dependency for the factory should be injected via the factories constructor, and you are only constructing the factory in one place, but the passing it as the dependency to everything that needs to create an order. The things which are getting orders from the factory are still calling the same method, CreateOrder() or whatever, and so that code is unchanged.

The dependencies should all be wired up in a single place, the composition root, and that should be the only place that needs to change, to add the new dependency to the factory

Answer 4

You tell the factory about the new dependency, and let it add it for you. The method call to the factory should be unchanged.

Answer 5

The factory pattern can ease the pain of adding a dependency, because a factory may contain state and, in fact, can encapsulate multiple dependencies (e.g. instead of providing three dependencies, all needed to invoke some object's constructor, you now provide only a single factory object, where the factory contains those three objects that are needed to be provided to the constructor).

To give an example, compare:

void DoIt(const DependencyA& a, const DependencyB& b) {
   // NOTE: "x" is a contrived additional variable that we add here to
   // justify why we didn't just pass DependencyC directly.
   int x = ComputeX(); 
   std::unique_ptr<DependencyC> dependency_c(new DependencyC(a, b, x));
   dependency_c->DoStuff();
}

And:

void DoIt(const DependencyCFactory& factory) {
  int x = ComputeX();
  std::unique_ptr<DependencyC> dependency_c(factory->Create(x));
  dependency_c->DoStuff();
}

Note that the second version required fewer dependencies to the method "DoIt". This does not mean that those dependencies aren't need in the entire program (indeed, the program still makes use of DependencyA and DependencyB in the implementaiton of the factory). However, by structuring it this way, that dependency can be isolated to just the factory code, which keeps other code simpler, makes it easier to change the dependencies of DependencyC (now only the factory, itself, needs to be updated, not every place that instantiates DependencyC), and can even have certain safety/security benefits (e.g. if DependencyA and DependencyB are sensitive such as database passwords or API keys, limiing their usage to the factory reduces the chances of mishandling, compared to cases where you pass these around everywhere that you need to use the databse or API, for example).

In the example given in the book, the reason why having a factory for the Order would have helped is that it would have reduced the number of places where the constructor is used directly; only the one place that created the factory would need to be modified to store the Customer as an additional field of the factory; none of the other uses of the factory would need to be modified. By comparison, without the use of the factory, direct uses of the constructor abound, and each one of them must be updated to somehow obtain access to the Customer object.