Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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:


  • 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.


  • Less discoverable, more difficult to skim code.
  • Some patterns, like serialization or reflection are more difficult (e.g. Activator<Foo>.CreateInstance())
share|improve this question
It's slower. You have to handle null reference anyway. – Amir Rezaei Nov 16 '10 at 18:43
@Amir Handling null is (Foo x = Foo.TryCreate(); if (x == null) { ... }). Handling a ctor exception is (Foo x; try { x = new Foo(); } catch (SomeException e) { ... }). When calling a normal method, I prefer exceptions to error codes, but with object creation, TryCreate seems cleaner. – dbkk Nov 16 '10 at 19:06
Would you in your validation make any type checking? – Amir Rezaei Nov 16 '10 at 19:18
up vote 6 down vote accepted

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.

share|improve this answer

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.