Static Factory Methods vs Constructors In C#

// Using the constructor
SqlConnection myConnection = new SqlConnection(connectionString);

// Using a static factory method
IDbConnection myConnection = SqlConnection.FromConnectionString(connectionString);

Pros of Static Factory Methods

No need to return a new instance

In constructors you always have to return a new object.

You can use method references

If you’re inclined to write your C# more in a functional way — you might appreciate that you can pass a reference to the method (or “method group” as they’re officially called) in your code. Contrast this:

// Static factory method - the method group can be passed in directly as a function reference
var bars = myFoo

// Constructors - you have to pass in a lambda that constructs the instance via new.
var bars = myFoo
.Select(f => new Bar(f));

You can name ‘em

For some objects, particularly objects that can be constructed in multiple similar ways — being able to put a name on the way you construct your objects can be a huge benefit. Let’s take an example of a Color class than can be constructed both via CMYK and RGB parameters.

// With constructors
var color = new Color(25, 25, 5, 80);
var color = new Color(100, 150, 50);

// With static factory methods
var color = Color.FromCMYK(25, 25, 5, 80);
var color = Color.FromRGB(100, 150, 50);

Factory Methods can return a different class

While New Foo() always has to return a new instance of the Foo class, Foo.FromBar can easily return an IFoo interface, or a subclass of Foo. A real-world example where this could be relevant:

// This could create an IpV4IpAddress that implements IIpAddress 
IIpAddress ipv4Address = IpAddress.FromString("");

// This could create an IpV6IpAddress that implements IIpAddress
IIpAddress ipv6Address = IpAddress.FromString("2001:0db8:0a0b:12f0:0000:0000:0000:0001")

There Are Things You Shouldn’t Do In Constructors

Generally people don’t expect constructors to do much of anything but construct an object. While you can do I/O, database access etc in constructors, most people don’t expect it. Convention-wise you’re free to do more work in a static factory method without anyone raising any eyebrows.

Cons of Static Factory Methods

Let’s look at the flip side of the coin

There Are Things You Shouldn’t Do In Constructors

Constructors are usually simpler by convention. When I call a constructor, I generally don’t expect it to do I/O or anything fancier than return a plain vanilla object with the properties I gave it. This makes constructors much less flexible as a construct, which can be both a blessing and a curse.

There’s more code

No matter what, you’re still going to need a constructor to actually construct the objects. The static factory method is more code, and code is a liabillity. It’s usually not very complex code, and usually the static factory methods aren’t particularly long either — so this is probably not a huge con.

They’re harder to find

Usually when I try to construct a new object, I look for the constructor first. It’s a little harder to find a static method via autocomplete — as they’re usually not distinguishable from other static methods.

  • You should always create one constructor that maps 1:1 to the fields internally in the class.
  • If you need to do anything fancy to create the object, such as IO, or you’re interested in caching objects and reusing them, use a static factory method.
  • If you need API stability, such as for library development, hide that constructor and use a static factory method because of the implementation flexibility it gives you.
  • If you have multiple different ways to create your class, create static factory methods and use those, because of the descriptiveness they give you.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Gustav Wengel

Gustav Wengel

Software Developer at SCADA Minds