Factory vs instance constructors

Question

I can\'t think of any reasons why one is better than the other. Compare these two implementations:

public class MyClass
{
    public MyClass(string fileName         


        

Answer 1

Note: What you have is not a static constructor, it's a static function that creates the instance rather than calling the instance constructor yourself. A static constructor is a different thing entirely.

The factory pattern is a classic example of using a function (static or not) to instantiate a type rather than using the constructor directly. Note that the actual instance constructor will get called no matter what, but the static function provides a layer of indirection that allows it to return an instance of any type that either is or inherits from the return type, rather than only instances that are the return type.

For example:

public abstract class BaseClass
{
    public static BaseClass Create(int parameter)
    {
        if (parameter == 1)
        {
            return new Class1();
        }
        else
        {
            return new Class2();
        }
    }
}

internal class Class1 : BaseClass
{
    //code here ...
}

internal class Class2 : BaseClass
{
    //code here ...
}

This allows you to hide Class1 and Class2 from external assemblies while still allowing the consumer to deal with something specialized.

Answer 2

As you can see, myClass is not following a "classic" factory pattern (where the class of the instance is not known/exposed outside the factory).

However in this case, the .NET framework team may not be aiming for a factory pattern, but I guess they do not want you to just new up the target class directly with a filename via a constructor. A factory might be overkill if only this class is being provided.

This pattern is sometimes seen in clone() methods, where an object can return an instance which is a kind of duplicate of itself.

Also maybe although the class is public, they might want to do some checks with the instantiation, filename, etc. and if they implemented a factory, the target class could still be created and invoked, bypassing the checks.

Answer 3

Not spilling out dependency to assemblies referring your assembly is another reason.

It seems like if calling a constructor for a class in another assembly, your assembly will be required to references all the assemblies that defines any of the types used by any overload. You can workaround this forced dependency by using differently named factory methods.

Example:

Assembly1.dll (requires ref to BarAssembly.dll not so obvious)

class Class1 { 
    void Main(){
        var foo = new Foo();
    }
}

Assembly2.dll (no need for ref to BarAssembly.dll here, as CreateFoo and CreateFooWithBar is not overloads)

class Class2 { 
    void Main(){
        var foo = CreateFoo();
    }
}

FooAssembly.dll (requires ref to BarAssembly.dll obvious)

class Foo { 
    public CreateFoo(){
        ...
    }
    public CreateFooWithBar(Bar bar){
        ...
    }
    public Foo(){
        ...
    }
    public Foo(Bar bar){
        ...
    }
}

BarAssembly.dll

class Bar { 
    public Bar(){
        ...
    }
}

Note: Observed on VS2013 building against .NET Framework 4.5

Answer 4

You can curry factory methods. Trying to curry a constructor gives you: a factory method.

I use this in some of my code that enumerates the Windows Device Manager tree. One of the classes lists the serial ports, each serial port has a connection factory property which returns a curried factory method with the port address (really ugly PNP device string) stored in internal state while the baud rate, stop bits, parity are all provided later.