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

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 2

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 3

Factories are typically objects with state, and they typically have a single function to instantiate an instance; any parameters would would be given to the constructor of the object being instantiated are provided to the constructor of the factory object or are known to the factory object in some other way. Thus, you would not need to pass any additional information to the factory; you would invoke the factory's instantiation function, and you would only have to modify the factory that got constructed to use the other constructor.

To make this more concrete, you might have something like this:

template<typename T> class Factory
{
    public:
        virtual T* instantiate()const=0;
};

// One possible implementation
class MyClassFactory1 : public Factory<MyClass>
{
      public:
          virtual T* instantiate()const { return new MyClass; }
};

// Another possible implementation
class MyClassFactory2 : public Factory<MyClass>
{
      public:
          MyClassFactory(ParamType1 p1, ParamType p2) : p1(p1), p2(p2) {}
          virtual T* instantiate()const { return new MyClass(p1,p2); }
      private:
          ParamType1 p1;
          ParamType2 p2;
};

// Code that uses it:
void blah(const Factory<MyClass>& f)
{
     // ...
     MyClass* x = f.instantiate(); // <= this line never needs to change
     // ...
}

Answer 4

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 5

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.