Static Create method — pros and cons compared with constructors

Question

What are the pros and cons of having static object creation methods over constructors?

class Foo {
  private Foo(object arg) { }

  public static Foo Create(object arg) {
    if (!ValidateParam(arg)) { return null; }
    return new Foo(arg);
  }
}

Few that I can think of:

Pros:

• Return null instead of throwing an exception (name it TryCreate). This can make code more terse and clean on the client side. Clients rarely expect a constructor to fail.
• Create different kinds of objects with clear semantics, e.g. CreatFromName(String name) and CreateFromCsvLine(String csvLine)
• Can return a cached object if necessary, or a derived implementation.

Cons:

• Less discoverable, more difficult to skim code.
• Some patterns, like serialization or reflection are more difficult (e.g. Activator<Foo>.CreateInstance())

Answer 1

The biggest drawback with static 'creators' is probably limiting inheritance. If you or the user of your library derives a class from your Foo, then Foo::Create() becomes pretty much useless. All logic defined there will have to be rewritten again in the inherited Create().

I'd suggest a compromise: define a constructor with trivial object initialization logic that never fails/throws, then define creator(s) with caching, alternate construction etc. You leave the possibility of deriving and you benefit from having creators for a given class.

Answer 2

Create is a Factory method. When I feel a need for this, I implement the Factory pattern, and define an interface to represent the contract for creating the object as well as an implementing class, which then gets injected where needed. This retains the advantages of moving the creation responsibility out of the class, but avoids (or at least makes more obvious) the limitations of performing object creation outside the class constructor.