Static factory methods vs Instance (normal) constructors?

In a language where both are available, would you prefer to see an instance constructor or a static method that returns an instance?

For example, if you're creating a String from a char[]:

1. String.FromCharacters(chars);

2. new String(chars);

In Effective Java, 2nd edition, Joshua Bloch certainly recommends the former. There are a few reasons I can remember, and doubtless some I can't:

• You can give the method a meaningful name. If you've got two ways of constructing an instance both of which take an int, but have different meanings for that int, using a normal method makes the calling code much more readable.
• A corollary of the first - you can have different factory methods with the same parameter list
• You can return null for "potentially expected failure" cases whereas a constructor will always either return a value or throw an exception
• You can return a type other than the declared (e.g. return a derived class)
• You can use it as a factory, to potentially return a reference to the same object several times

The downsides:

• It's not as idiomatic, currently - developers are more used to seeing "new"
• If you see "new" you know you're getting a new instance (modulo the oddity I mentioned recently)
• You need to make appropriate constructors available for subclasses
• In C# 3, constructor calls are able to set fields/properties in a compact manner with object initializer expressions; the feature doesn't apply to static method calls

I write a constructor when creating the instance has no side effects, i.e. when the only thing the constructor is doing is initializing properties. I write a static method (and make the constructor private) if creating the instance does something that you wouldn't ordinarily expect a constructor to do.

For example:

public class Foo
{
   private Foo() { }

   private static List<Foo> FooList = new List<Foo>();
   public static Foo CreateFoo()
   {
      Foo f = new Foo();
      FooList.Add(f);
      return f;
   }
}

Because I adhere to this convention, if I see

Foo f = Foo.CreateFoo();
Bar b = new Bar();

while reading my code, I have a very different set of expectations about what each of those two lines is doing. That code isn't telling me what it is that makes creating a Foo different from creating a Bar, but it's telling me that I need to look.

I've been working on a public API recently, and I've been agonizing over the choice of static factory methods versus constructor. Static factory methods definitely make sense in some instances, but in others it's not so clear and I'm uncertain whether consistency with the rest of the API is reason enough to include them over constructors.

Anyway, I came across a quote from a Bill-Venners interview with Josh Bloch that I found helpful:

> When you are writing a class, you can > run down the my book's list of the > advantages of static factories over > public constructors. If you find that > a significant number of those > advantages actually apply in your > case, then you should go with the > static factories. Otherwise you should > go with the constructors. > > Some people were disappointed to find > that advice in my book. They read it > and said, "You've argued so strongly > for public static factories that we > should just use them by default." I > think the only real disadvantage in > doing so is that it's a bit > disconcerting to people who are used > to using constructors to create their > objects. And I suppose it provides a > little less of a visual cue in the > program. (You don't see the new > keyword.) Also it's a little more > difficult to find static factories in > the documentation, because Javadoc > groups all the constructors together. > But I would say that everyone should > consider static factories all the > time, and use them when they are > appropriate.

Having read that quote, and the study that Uri mentioned*, I'm feeling inclined to err in favour of constructors unless there are compelling reasons to do otherwise. I think a static factory method without good cause is probably just unnecessary complexity and over-engineering. Though I might well change my mind again by tomorrow...

*Unfortunately this study focused less on static factory methods and more on the factory pattern (where a separate factory object exists to create new instances), so I'm not sure one can really draw the conclusion that static factory methods confuse many programmers. Although the study did give me the impression that they often would.

If your object is immutable, you may be able to use the static method to return cached objects and save yourself the memory allocation and processing.

There's a paper from ICSE'07 that studied the usability of constructors vs. factory patterns. While I prefer factory patterns, the study showed that developers were slower in finding the correct factory method.

http://www.cs.cmu.edu/~NatProg/papers/Ellis2007FactoryUsability.pdf

It depends. For languages in which using an instance constructor is "normal", I would generally use one unless I had good reason not to. This follows the principle of least surprise.

By the way, you forgot another common case: A null/default constructor paired with an initialization method.

Static Method. Then you can return a null, rather than throwing an exception (unless a reference type)

I prefer instance constructor, just because that makes more sense to me, and there's less potential ambiguity with what you're trying to express (ie: what if FromCharacters is a method which takes a single character). Certainly subjective, though.

I personally prefer to see a normal constructor, since contructors should be used to construct. However, if there is a good reason to not use one, ie if FromCharacters explicitly stated that it didn't allocate new memory, it would be worthwhile. The "new" in the invocation has meaning.

As Jon Skeet paraphrased Josh Bloch, there are a number of reasons why a static factory method is preferable to a constructor in many cases. I would say that if the class is a simple one with no expensive setup or complicated usage, stay with the idiomatic constructor. Modern JVMs make object creation extremely fast and cheap. If the class might be subclassed or you are able to make it immutable (a big advantage for concurrent programming, which is only going to get more important), then go with the factory method.

One more tip. Don't name the factory method Foo.new* or Foo.create*. A method with these names should always return a new instance, and doing so misses one of the big advantages of the factory method. A better naming convention is Foo.of* or Foo.for*. The Google Guava library (formerly Google Collections Library) does a great job of this, imho.

Of course, there are several advantages of static factory methods over constructors.

1. factory methods help us to write flexible code. Whereas constructors made it tightly coupled.
2. Static factory methods improve the readability since these allow you to create different instances.
3. You can return a cached object. For example getInstance() in Singleton.