What is the advantage of hiding the class constructor in favor of a static method (no .NET)?

Question

My leader uses this pattern in ALL his classes (I’ll give the examples in C#, but it goes for any . NET language):

public class MeuTipo
{
    private MeuTipo() { } // esconder o construtor

    public static MeuTipo CriarMeuTipo()
    {
        MeuTipo meuTipo = new MeuTipo();
        return meuTipo;
    }
}

I really don’t understand why this is happening. Its classes are not even immutable (although I also do not think that there would be an advantage even if the class were immutable), so, besides this seems to me a pattern without much utility, it also prevents us from using constructors with properties, as for example... (I will use a supposed class Pessoa)

new Pessoa { Nome = "João", Sobrenome = "Doe", (...) } // não é possível nesse padrão

Therefore, we are obliged to imagine all the scenarios in which a constructor would be possible. For example, supposing that on one occasion the Pessoa can start without any data, or only with the first name, or with both names, we are obliged to do the class like this:

public class Pessoa {
    private string _nome;
    public string nome {
        get { return this._nome; }
        set { this._nome = value; }
    }

    private string _sobrenome;
    public string sobrenome {
        get { return this._sobrenome; }
        set { this._sobrenome = value; }
    }

    private Pessoa() { }
    public static Pessoa CriarPessoa() {
        return CriarPessoa(null);
    }
    public static Pessoa CriarPessoa(string nome) {
        return CriarPessoa(null, null);
    }
    public static Pessoa CriarPessoa(string nome, string sobrenome) {
        Pessoa pessoa = new Pessoa();
        pessoa.nome = nome;
        pessoa.sobrenome = nome;
        return pessoa;
    }
}

While we could do so:

public class Pessoa {
    public string Nome { get; set; }
    public string Sobrenome { get; set; }
}

I really can’t understand why I go to so much trouble to lose a language resource, so I can’t help but think that there might be a reason for it. If there is a reason, be it Design Patterns or some kind of reason for legacy code, can anyone enlighten me?

Note: I NAY I want opinions here, because this is not a review site. I asked this question because I believe that some programmer longer than me, or who has worked with Object Orientation outside the . Give me an answer to why that would be an advantage.

By the way, my leader used Java in the past. So I think there is an answer certain to that question.

Answer 1

This pattern is useful in rare cases.

One is to implement the Singleton standard, in which the constructor is hidden, and a static method is used to create a new Singleton or return the existing one. Simply:

public class MySingleton{    
    private static MySingleton _singleton = null;

    private MySingleton() { }

    public static MySingleton GetInstance() {
        if(_singleton == null)
            _singleton = new MySingleton();
        return _singleton;
    }
}

(Note: the above example could be improved with double-checked Locking for example to ensure thread Safety)

However, in most cases they all Private constructors are nothing but trouble. Prevents unit tests in isolation, cannot mock dependencies, cannot inject dependencies, etc.

With all due respect, your leader should go back to college...

Answer 2

There are two standards (which I remember now) that benefit from builders that are not public:

• Factory

• Singleton

Neither of these two patterns benefits from a static construction method... Singleton has a static method (or property), but it is not a construction method but a obtaining the instance, which may or may not build the object.

There is, however, a purpose for static construction methods:

• construction with inference of argument types

• construction with semantics (very important for maintainability)

Standard Factory

The pattern Factory determines that an object is built by a objects. This object factory implements an interface so that one can use inversion control (Ioc) of building objects, ie externalize the construction of objects, being that the object factory becomes a dependency of all who need to build the object.

public interface IFabricaMeuObjeto
{
    MeuObjeto Criar(int exemploParametro);
}

In this pattern the object builder is not public, so programmers are not induced to create the object using a constructor, rather than using the factory of objects. In this case it would not be private but yes internal.

public class MeuObjeto
{
    internal MeuObjeto()
    {
    }

    public int Inteiro { get; set; }
}

Utilities of the Factory standard

This is a very useful pattern as it allows in mocking the construction of new objects, in addition to enabling aspect-oriented programming, for example, if you want to log every time an object is created, you can implement the object factory interface, getting the original factory and implement the LOG thus:

public class FabricaMeuObjeto : IFabricaMeuObjeto
{
    public MeuObjeto Criar(int exemploParametro)
    {
        return new MeuObjeto { Inteiro = exemploParametro };
    }
}

public class FabricaMeuObjetoLog : IFabricaMeuObjeto
{
    IFabricaMeuObjeto original;

    public FabricaMeuObjetoLog(IFabricaMeuObjeto original)
    {
        this.original = original;
    }

    public MeuObjeto Criar(int exemploParametro)
    {
        return this.original.Criar(exemploParametro);
        Log.CriarLog("MeuObjeto foi criado.");
    }
}

On system startup, using some dependency injection framework:

container.Register<IFabricaMeuObjeto, FabricaMeuObjetoLog>();

I used the Simpleinjector in this example.

Singleton standard

The Singleton pattern is very useful for objects that only need one the entire execution time of the program. Thus, the constructor of the object should not be public, so as not to induce programmers who use object to error.

The Singleton is obtained from a static call, however I see no problems in make this Singleton be obtained from an injection framework of dependencies. Simpleinjector (which is what I use) supports a form of injection in which is always injected the same object, when it is needed... for me is a good way to integrate two very useful patterns, providing the single instance through a service interface:

public interface ISingletonService
{
    MeuObjeto PegarInstancia();
}

public interface SingletonService
{
    public MeuObjeto PegarInstancia()
    {
        return MeuObjeto.Instancia;
    }
}

public class MeuObjeto
{
    internal static MeuObjeto Instancia { get; private set; }

    static MeuObjeto()
    {
        Instancia = new MeuObjeto();
    }

    private MeuObjeto()
    {
    }
}

At system startup, using some dependency injection framework, which in this case is the Simpleinjector:

container.Register<ISingletonService, SingletonService>(Lifestyle.Singleton);

Construction with inference of generic types

One utility I see for static building methods is to make inference of types of a constructor of an object that has generic parameters, once that C# does not accept to infer types when using the operator new. That doesn’t work on C#:

public class MeuObjeto<T>
{
    public T Valor { get; set; }

    public MeuObjeto(T valor)
    {
        this.Valor = valor;
    }
}

...

var obj = new MeuObjeto( 1 ); // o C# não vai inferir o construtor a ser usado

The following build error will occur:

Using the Generic type 'Meuobjeto' requires 1 type Arguments

For this can be created a static method, in another class, so that can take advantage of type inference to create the object:

public static class MeuObjeto
{
    public static MeuObjeto<T> Criar<T>(T valor)
    {
        return new MeuObjeto<T>(valor);
    }
}

...

var objInt = MeuObjeto.Criar( 1 ); // isso funciona
var objStr = MeuObjeto.Criar( "string" ); // isso também funciona

Object construction with semantics

When a constructor has a specific meaning, it would be better expressed through a method with a specific name, I prefer to use construction methods than the operator new. A good example in the framework . Net is the TimeSpan, that has several static construction methods, which could not be expressed using builders:

• TimeSpan.FromDays

• TimeSpan.FromSeconds

• TimeSpan.FromTicks

When there is semantics in the construction, probably the name of the method will not be only Criar... because "create" does not present any better semantics than the own new.

Answer 3

This way of working with the builder is widely used in the Singleton design pattern. To answer the question, it is not good practice to treat all classes in this way. Try to talk to your leader and understand why you do it this way.

Answer 4

Immutable Objects.

The default setting for immutable objects is usually the definition of a private/protected constructor, the absence of sets, and the definition of constructors for the correct completion of the instance.

The code gets more "strange", but for those who want to work with parallel programming (and immutable objects are essential in this programming model), there is no other way.

This also applies to hybrid languages, for example Scala (functional and object-oriented).

If the intention is not to work with immutable objects and there is no need for a parallelism solution, I see no point in using this pattern. Immutable objects tend to decrease the bugs of side effects, but requires good architectural planning.

See a definition in Value Object