C# de membre de l'initialisation d'une variable; les meilleures pratiques?

Est-il préférable d'initialiser les variables de membre de classe sur la déclaration

private List<Thing> _things = new List<Thing>();
private int _arb = 99;

ou dans le constructeur par défaut?

private List<Thing> _things;
private int _arb;

public TheClass()
{
  _things = new List<Thing>();
  _arb = 99;
}

Est-ce simplement une question de style ou il y a la performance de compromis, d'une façon ou de l'autre?

InformationsquelleAutor Steve Crane | 2008-11-18
  1. 75

    En termes de performance, il n'y a pas de différence réelle; champ initialiseurs sont mis en œuvre en tant que constructeur de la logique. La seule différence est que le champ des initialiseurs d'arriver avant tout "de base"/"ce" constructeur.

    Le constructeur approche peut être utilisée avec des propriétés implémentées automatiquement (champ initialiseurs ne peut pas) - c'est à dire

    [DefaultValue("")]
public string Foo {get;set;}
public Bar() { //ctor
  Foo = "";
}

    Autre que cela, j'ai tendance à préférer le domaine de l'initialiseur de la syntaxe; je trouve qu'il garde les choses localisée à - dire

    private readonly List<SomeClass> items = new List<SomeClass>();
public List<SomeClass> Items {get {return items;}}

    Je n'ai pas à aller à la chasse en haut et en bas pour trouver où il est affecté...

    L'exception évidente est l'endroit où vous avez besoin pour effectuer une logique complexe ou de traiter avec les paramètres du constructeur, auquel cas le constructeur-en fonction d'initialisation est le chemin à parcourir. De même, si vous disposez de plusieurs constructeurs, il serait préférable pour les champs pour avoir toujours définie de la même manière que vous pourriez avoir ctors comme:

    public Bar() : this("") {}
public Bar(string foo) {Foo = foo;}

    edit: comme un commentaire, remarque que ci-dessus, si il y a d'autres champs (non illustré) avec le champ des initialiseurs, alors qu'ils ne sont directement initialisé dans le constructeur que l'appel base(...) - à-dire le public Bar(string foo) ctor. L'autre constructeur ne pas champ exécuter les initialiseurs, car il sait qu'ils sont fait par le this(...) ctor.

    • Je sais que c'est un vieux post mais j'ai une question: Qu'entendez-vous par "les constructeurs d'appel de base(...)"? vous Bar(chaîne foo) {Foo = foo;} ne semble pas être l'appel de : base(), ou fait-il implicitement? Merci pour votre aide.
    • pour un class, chaque constructeur implicite : base(), sauf si vous ajoutez quelque chose de plus précis, ce qui pourrait être : base(123, "abc"), ou pourrait être : this(123, "abc").
    • Donc, Est l'initialisation de la commande (1)fieldInitializer(2)BaseConstructor(3)LocalConstructor
    InformationsquelleAutor Marc Gravell
  2. 9

    En fait, le champ des initialiseurs comme vous le démontrer est un raccourci pratique. Le compilateur fait des copies le code d'initialisation au début de chaque instance constructeur que vous définissez pour votre type.

    Cela a deux conséquences: d'abord, un champ de code d'initialisation est dupliqué dans chaque constructeur et, d'autre part, tout le code que vous incluez dans votre constructeur pour initialiser les champs de valeurs spécifiques sera en effet re-assigner les champs.

    Donc en terme de performance, et en ce qui concerne le code compilé de la taille, vous êtes mieux de déplacer le champ des initialiseurs dans les constructeurs.

    D'autre part, l'impact sur les performances et le code 'gonfler' sera généralement négligeable, et que le champ d'initialiseur de syntaxe a l'avantage de diminuer le risque que vous pourriez oublier d'initialiser le terrain, dans l'un de vos constructeurs.

    • La performance du point ne s'applique que si vous ré-assigner les valeurs (c'est à dire qu'il ne s'applique pas dans le code d'origine). De même, la "dilatation" (qui est minuscule) s'applique uniquement aux ctors que l'appel de la base de(...) - de sorte que vous pouvez passer ce avec un privé ctor (posté) - que ce ctor va initialiser les champs.
    • Savez-vous si cette réaffectation qui se passe réellement dans la pratique? Le compilateur doit être en mesure de retirer l'excédent d'initialisation, si elle ne change pas la sémantique du programme.
    InformationsquelleAutor Tor Haugen
  3. 4

    L'une des principales limites du terrain initialiseurs est qu'il n'y a aucun moyen de les envelopper dans un try-finally bloc. Si une exception est levée dans un champ d'initialiseur, toutes les ressources qui ont été allouées dans les précédents initialiseurs sera abandonné; il n'y a aucun moyen de l'empêcher. D'autres erreurs dans la construction peuvent être traitées, si maladroitement, par le fait d'avoir protégé constructeur de base accepter une IDisposable par référence, et pointant à sa première opération. On peut alors éviter d'appeler le constructeur, sauf par l'intermédiaire de méthodes de fabrique qui, dans des cas d'exception appeler dispose sur la partie objet créé. Cette protection permettra de nettoyage de IDisposables créé en dérivés de la classe des initialiseurs si le principal constructeur de la classe échoue après la "contrebande" une référence à l'objet nouveau. Malheureusement, il n'y a aucun moyen de fournir cette protection si un champ d'initialiseur échoue.

    InformationsquelleAutor supercat
  4. 2

    Utiliser soit le champ d'initialiseurs ou de créer une fonction Init (). Le problème avec mettre ces choses dans votre constructeur, c'est que si jamais vous avez besoin d'ajouter un 2ème constructeur, vous vous retrouvez avec des copier/coller le code (ou vous l'ignorer, et à la fin avec des variables non initialisées).

    Je voudrais soit initialiser où déclarée. Ou ont le constructeur(s) de l'appel d'une fonction Init ().

    • Remarque : cet() la chaîne des constructeurs en Marc Gravel du post ci-dessus. C'est une bien meilleure pratique de l'écriture distincte de la fonction Init()-fonctions.
    InformationsquelleAutor GeekyMonkey
  5. 1

    Pour les variables d'instance, c'est en grande partie une question de style (je préfère à l'aide d'un constructeur). Pour les variables statiques, il y a un avantage en matière de performances à l'initialisation en ligne (pas toujours possible, bien sûr).

    InformationsquelleAutor Kent Boogaart
  6. 0

    C'est vraiment à vous.

    J'ai souvent les initialiser en ligne, parce que je n'aime pas avoir un constructeur quand je n'en ai pas vraiment besoin (j'aime les petits des classes !).

    InformationsquelleAutor Nico
  7. 0

    Sur ajouté des points au - dessus de Vous de toujours avoir un constructeur lors de la mise en œuvre de classes qui ont une mise en œuvre. Si vous ne déclarez pas un, alors la valeur par défaut de l'instructeur est déduit par le compilateur [public Foo(){}]; un constructeur qui ne prend pas d'arguments.

    Bien souvent, je tiens à offrir les deux approches. Permettre à des constructeurs pour ceux qui souhaitent les utiliser et d'autoriser le Domaine des Initialiseurs pour les situations où vous souhaitez utiliser une procédure simplifiée ou par défaut de mise en œuvre de votre classe /type. Cela ajoute de la souplesse à votre code. Gardez à l'esprit que n'importe qui peut utiliser la valeur par défaut du champ de l'initialiseur s'ils choisissent ... assurez-vous de déclarer manuellement si vous offrez plus d'un constructeur - public: Foo(){}

    InformationsquelleAutor Qubits