Static factory methods vs Instance (normal) constructors?

Question

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

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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

Answer 5

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.

Answer 6

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.