Purpose of factory objects/benefit over using same instance to return type

Question

What is the benefit of a static factory class as opposed to using an instance of the same object to return that object?

For example, from the N2 CMS, take a look at this code:

Newspage news = Factory.Persister.Get(itemID);

// Variable for news can set news related properties.

Factory.Persister.Save(news);

Factory is static and I am aware of what factory objects do/are, but I don't see the benefit of a static factory (Which probably takes the responsibility of setting up different types) as opposed to using the Newspage object for this.

Thanks

Answer 1

One school of thought is that if you create an object and use an object, then you're tightly bound to that object. A factory allows you to abstract away what type an object actually is, so that you're not dependent on the particular implementation class. For example, what if Newpages in the future need to be created from a Google cache rather than from an NNTP source? Do you want to add new constructors and logic to all the places that create newspages, or would you prefer to abstract that away in a factory class?

That said, I don't think a static factory is a great idea either. How would you swap it out with an implementation that returns fake objects for unit testing purposes? You should really look into dependency injection so that you're not tied to static objects. The only static thing defined by some working applications is main().

Answer 2

I think the benefit of a static factory over a non-static factory is closely tied to the benefits of the use of static. Mainly, a static method or function is used if you never want to actually create an object in order to call that method. If you want to simply get something from the factory you don't have to create an object first. You just say hey give me what you got and you get it.

Answer 3

As I understand it, the advantage of a factory is that you can ask it to create an object without knowing anything other than the magic number that identifies the object class.

This is a real advantage in a plugin architecture, where you want to write code that can use objects that are developed long after or completely separately from the code that uses them.

But if all of the code that uses an object is in the same binary as the object itself, and there is no need for separate compilation, there is no real advantage in the factory other than as a formal/conceptual separation of implementation from use.

Answer 4

There are a few advantages of a static factory instead of using a constructor:

• A constructor called with new is usually required to create a new object each time it is called. However, a static factory is not, so you can reuse immutable objects and cache frequently used values, which can lead to improved performance.

• Static factories have names; constructors don't. In most OOP languages, they usually need to have the same name as the class and may vary only in their type and number of arguments. But static factories can have different names as well as any type and number of arguments.

• Static factories can grab a specific existing object knowing only one piece of the object, if needed, such as its identifier. Or they can make a completely new object if that one doesn't exist. Again, it's tougher to do that with a constructor, depending on what language you're using.

• With static factories, you can control and regulate which objects exist at any given time -- not so much with new.

• Static factories can return objects of any subtype, but creating an object using a constructor will only create objects of a specific type. Using a static factory in this way creates a nice separation between interface and implementation.