What is the advantage of hiding new from client by factory design pattern

Question

I have read the factory design pattern recently, in that he had mentioned one of the problem in normal approach is

*Need to use the new keyword in client classes.

So by using factory we have achieved this (client doesn't use new). But what is the advantage of hiding new from the client?

One problem is when client uses the new key word, he is then responsible to delete that memory. Any how if we use factory also, we still need to do that, when client creates a object at the end the client has to delete it (factory wont delete them).

I understand, other advantages like, reusing the existing code and no need to change client side code. but I got confused what we have achieved by hiding new (or even class) from client.

Thanks in advance.

Overtop

Answer 1

I don't think the primary purpose of the factory pattern is to "hide new from the client." The primary purpose is to "hide which new is used and how." It gives you the freedom to choose in your implementation which class you'll actually create.

For example, you can offer an interface Renderer in your factory:

class Renderer
{
  // ...
};

struct RendererFactory
{
  Renderer* createRenderer() const;
};

Renderer* RendererFactory::createRenderer() const
{
#ifdef WIN32
  if (AskWinApiIfOpenGlEnabled())
    return new OpenGlRenderer();
  else
    return new DirectXRenderer();
#else
  return new OpenGlRenderer();
#endif
}

In C++, an additional advantage of providing a factory function is to ensure proper memory management. If you change the code above to return std::unique_ptr<Renderer> (which is the right thing to do), you protect the client from Murphying a memory leak (which they could do by not calling delete on the return value in the raw pointer case)¹.

It's even possible you want your factory to retain partial ownership of the object (so that it can reuse them), so you'd do something like this:

class RendererFactory
{
  std::weak_ptr<Renderer> cachedRenderer;

public:
  std::shared_ptr<Renderer> createRenderer();
};

std::shared_ptr<Renderer> RendererFactory::createRenderer()
{
  if (auto r = cachedRenderer.lock())
    return r;
  auto r = std::make_shared<RendererSubClass>();
  cachedRenderer = r;
  return r;
}

To summarise, the factory-based creation design patterns (Abstract Factory and Factory Method) give you more control over the way creation and initialisation happen.

---

¹ Of course, they can still Machiavelli a memory leak by doing createRenderer().release(), but then it's a active action on their part and not just omission.

Octosyllabic

Answer 2

Factory pattern is not intended to hide the use of new from client. And yes you have to call delete on the object conjured up by new within the factory.

Main advantage of factory pattern is that it localizes object creation at one place. So, any changes in the hierarchy can effect only this much portion of code which is just a specialization of general rule that any changes in the software should effect minimum part of code.

Cantwell

Yes but in every article people are saying about this, apart from other advantages include what ever you said, people are mentioning about we are hiding a class name from a client and new from the client. simple article I read is : codeproject.com/Tips/469453/… – Overtop

This is from the article( under advantages) you mentioned "Suppose we want to add a decoupled structure and don’t want to disturb the client environment again and again, this pattern is very useful. The factory class will take all the burden of object creations." – Cantwell

@Durga Hiding the class name is important if you are returning a pointer to a polymorphic type. The client only needs to know about the base or "interface" type, and not about all of its implementations. Whether hiding new is an advantage is debatable, but sometimes the factory comes with different create/release mechanisms. – Mayorga

Answer 3

One advantage is that you do not have to worry about any of the dependencies that are required in order to create the object. By using the factory, you can simply abstract all the references needed. This is primarily because the client does not need to create nor have to know the details required to build.

Pussy

Answer 4

The factory patterns (simple factory, factory method and abstract factory) all have the advantage of hiding details of product creation from clients. It's more than just the new, even though that keyword often appears when objects are created. There are lots of other details, such as the name of the subclass, the parameters of the constructor, etc. The point is that you want to hide this information from the client, because if it changes, you only update it in the factory (as opposed to the code in all the clients if there was no factory).

The crux of your question seems to be that the responsibility for handling memory doesn't go away, even if the client doesn't use the new operation.

There are related questions on SO:

• Where to delete an object created by factory?
• Which design pattern is the opposite of the Factory pattern?

I personally like the idea that if a factory has the responsibility to encapsulate creating an object, then it should also encapsulate the responsibility for un-creating it. That is, it should have something like a delete method (opposite of create).

Gharry