¿Es una mala práctica para inicializar los campos fuera de un constructor explícito

Question

Duplicar posible:
Initialize class fields in constructor or at declaration?

Estamos discutiendo acerca de las prácticas de codificación. Los ejemplos aquí son un poco demasiado simples, pero el verdadero negocio tiene varios constructores. Para inicializar los valores simples (por ejemplo, fechas a su valor mínimo), he movido el código de los constructores a las definiciones de campo.

public class ConstructorExample 
{ 
    string _string = "John"; 
} 

public class ConstructorExample2 
{ 
    string _string; 

    public ConstructorExample2() 
    { 
     _string = "John"; 
    } 
} 

¿Cómo debe ser realizada por el libro? Tiendo a ser muy caso por caso y tal vez soy un poco flojo sobre este tipo de cosas. Sin embargo, creo que Occams razor me dice que mueva la inicialización de múltiples constructores. Por supuesto, siempre podría mover esta inicialización compartida en un método privado.

La pregunta es esencialmente ... ¿Inicializar campos en los que se definen de forma opuesta a la del constructor?

El argumento que estoy enfrentando es uno de manejo de errores, pero no creo que sea relevante, ya que no hay excepciones posibles que no se recojan en tiempo de compilación.

Answer 1

No es necesariamente malo para inicializar valores fuera del constructor, y el problema que tenemos aquí:

string _string; 

    public ConstructorExample2() 
    { 
     _string = "John"; 
    } 

Es que si usted tiene varios constructores no hay que olvidar a cualquiera
1. Fecha _STRING en cada constructor
2. Separe la lógica en un método común y llame a ese método en cada constructor
3. Llame al constructor con la lógica que contiene, desde los otros constructores. (Encadena los constructores)
Ahora bien, esto no es necesariamente un problema, pero debes recordar hacerlo. Inicializándolo fuera del constructor, está hecho para ti. Es una cosa menos que debes recordar hacer.

Answer 2

Prefiero inicializar campos simples como ese fuera del constructor.

No debería causar ningún problema ya que la compilación en realidad mueve esas inicializaciones al constructor en tiempo de compilación de todos modos.

Answer 3

Microsoft FxCop por defecto recomienda inicializadores de campo sobre el uso del constructor. This question también es un duplicado de este y debe proporcionar alguna información.

Con clases estáticas, deberá tener en cuenta algunas sutilezas que se tratan en this question.

Answer 4

Si la inicialización de la variable será la misma, no importa qué argumentos se pasen al constructor, entonces no tiene sentido alterar el método del constructor con el código de inicialización innecesario. En este caso, me inicializo en el lugar.

Answer 5

Inisializar los campos en el constructor es mejor. De esta forma si/cuando se agrega un constructor diferente, usted sabe que todos los campos comienzan con valores nulos/predeterminados y puede inicializarlos apropiadamente.

Answer 6

En el ejemplo anterior, la asignación de "John" a _string no tiene una dependencia lógica en ninguna variable y, por lo tanto, debe estar fuera del constructor en el inicializador de campo.

Mientras no sea posible inicializar el objeto en un estado no utilizable, entonces no importa.

Cuando se compila el código, ambos enfoques serán los mismos de todos modos.

Answer 7

Tenga en cuenta que todas las inicializaciones de nivel de declaración de campo se realizarán una vez por cada cadena de constructor, incluso si el constructor por sí solo establece el campo en otra cosa.

Si encadena constructores juntos, los campos se inicializarán en el primer constructor común al que se llama.

vistazo a este ejemplo:

using System; 

namespace ClassLibrary3 
{ 
    public class Class1 
    { 
     private string _Name = "Lasse"; 

     public Class1() 
     { 
     } 

     public Class1(int i) 
      : this() 
     { 
     } 

     public Class1(bool b) 
     { 
      _Name = "Test"; 
     } 
    } 
} 

Este código se compila como esto:

using System; 

namespace ClassLibrary3 
{ 
    public class Class1 
    { 
     private string _Name; 

     public Class1() 
     { 
      _Name = "Lasse" 
     } 

     public Class1(int i) 
      : this() 
     { 
      // not here, as this() takes care of it 
     } 

     public Class1(bool b) 
     { 
      _Name = "Lasse" 
      _Name = "Test"; 
     } 
    } 
} 

Answer 8

No estoy seguro sobre C#, pero en el código fuente de Java que parecen preferir el constructor, ejemplo:

public class String{ 
    char[] value; 
    int offset; 
    ... 
    public String(){ 
     value = new char[0]; 
     offset = 0; 
     ... 
    } 
} 

Answer 9

Creo que para inicializaciones simples como eso, está bien hacerlo en la declaración. Sin embargo, no entiendo el argumento de manejo de errores. Incluso si hay una excepción en la inicialización, creo que encontrará que su mecanismo normal de manejo de errores funcionará de la misma manera. Todavía lanzará una excepción cuando llame al constructor.

Answer 10

Tiendo a inicializar cosas en el programa de acceso get, donde se usan por primera vez. Si es nulo, entonces inicializa y todo eso.