¿Hay algún beneficio o inconveniente cuando un constructor implementa otro?

Question

Si tengo una clase como esta:

public class Foo 
{ 
    public IEnumerable<Bar> Bars { get; set; } 

    public Foo() 
    { 
     Bars = new List<Bar>(); 
    } 
} 

En algún momento me re-factor de la clase y añadir un constructor secundaria que implementa el primero de esta manera:

public class Foo 
{ 
    public IEnumerable<Bar> Bars { get; set; } 

    // some more properties were added 

    public Foo() 
    { 
     Bars = new List<Bar>(); 
    } 

    public Foo(string parameter): this() 
    { 
     .... some code here 
    } 
} 

que podría tener también escrito es similar a esto:

public class Foo 
{ 
    public IEnumerable<Bar> Bars { get; set; } 

    // some more properties were added too 

    public Foo() 
    { 
     InitilizeFoo(); 
    } 

    public Foo(string parameter) 
    { 
     InitilizeFoo(); 
     .... some code here 
    } 

    private void InitializeFoo() 
    { 
     Bars = new List<Bar>(); 
    } 
} 

al ver ambos enfoques de trabajo en este escenario, es que hay un beneficio o inconveniente en el uso de uno sobre el otro?

hereda constrcutors más eficiente y hacer que el código ejecuta más rápido o hay un inconveniente, que no sé acerca de hacer la segunda aplicación más eficiente en su lugar?

Answer 1

Una de las principales ventajas de tener una llamada al constructor a otro constructor es que se puede establecer sólo lectura campos de esa manera, no se puede hacer eso llamando a un método no-constructor.

Por ejemplo:

public class Foo 
{ 
    private readonly int myNumber; 

    public Foo() : this(42) 
    { 
    } 

    public Foo(int num) 
    { 
     myNumber = num; 
    } 
} 

En cuanto al rendimiento, es probable que no más o menos eficiente que llamar a otro constructor que llamar a otro método, pero es más fácil de leer, en mi opinión, para un constructor para llamar a otro constructor que llamar a un método privado separado cuyo único punto debe ser llamado por un constructor.

Podría, por supuesto, haber situaciones en las que tiene un método separado tiene sentido, y ciertamente no es "malo" per se. El encadenamiento de constructores simplemente se lee mejor para muchos para la mayoría de los usos, y no hay un impacto negativo en el rendimiento.

ACTUALIZACIÓN: I realizó 10.000.000 iteraciones de cada trayecto (encadenado vs método de inicialización privado) y los resultados fueron tan cerca que eran casi indistinguibles:

Initializer Method took: 84 ms for 10,000,000 iterations, 8.4E-06 ms/each. 
Chained Constructors took: 81 ms for 10,000,000 iterations, 8.1E-06 ms/each. 

Así que en realidad, en cuanto al rendimiento casi no hay beneficio de cualquier manera. El principal beneficio es con los constructores encadenados se pueden establecer readonly campos, y en la mayoría de los casos es más fácil de leer.

Answer 2

La clave es reducir la cantidad de código duplicado. En este caso, llamar al constructor base desde un constructor parametrizado reduce las posibilidades de agregar un error más tarde después de olvidarse de actualizar ambos.

Answer 3

encadenamiento constructores es una buena manera de hacer cumplir SRP y el programa de flujo. Ocultar el código de inicialización dentro de una función independiente Initialize() podría tener sentido si hay otras situaciones en el ciclo de vida del objeto donde también podría querer "Inicializarlo"; quizás si quisieras poder crear instancias rápidas e iniciarlas de forma lenta. Pero si el único momento válido en el ciclo de vida para ejecutar esa funcionalidad es durante la creación de instancias, y la inicialización es un conjunto bien definido de pasos discretos que deben tomarse en orden, el encadenamiento facilita eso.

Answer 4

Una ventaja de tener una función Initialise() es en caso de que desee restablecer su objeto; simplemente puede llamar a la función init nuevamente en lugar de eliminar & recrear el objeto.

Answer 5

que podría quemarse por decir esto, pero yo prefiero usar los parámetros por defecto en este caso:

public Foo(string parameter = null) 
{ 

} 

He tenido casos en los que tenía 10 - 15 parámetros opcionales y tiene 15 diferentes constructores no era una solución elegante en mi opinión. Creo que los parámetros predeterminados solo se reintrodujeron en el marco 4.0.