Инициализация переменной-члена C#;лучшая практика?

StackOverflow https://stackoverflow.com/questions/298183

  •  08-07-2019
  •  | 
  •  

Вопрос

Лучше ли инициализировать переменные-члены класса при объявлении?

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

или в конструкторе по умолчанию?

private List<Thing> _things;
private int _arb;

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

Это просто вопрос стиля или есть ли компромиссы в производительности, так или иначе?

Это было полезно?

Решение

С точки зрения производительности, нет никакой разницы; инициализаторы полей реализованы как логика конструктора. Единственное отличие состоит в том, что инициализаторы полей происходят до какого-либо «базового» / «этого» конструктор.

Конструкторский подход может использоваться с автоматически реализуемыми свойствами (инициализаторы полей не могут) - т.е. 

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

Кроме этого, я предпочитаю использовать синтаксис инициализатора поля; Я считаю, что это держит вещи локализованы - т.е. 

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

Мне не нужно охотиться вверх и вниз, чтобы найти, где это назначено ...

Очевидное исключение - когда вам нужно выполнить сложную логику или иметь дело с параметрами конструктора - в этом случае инициализация на основе конструктора - это путь. Аналогично, если у вас есть несколько конструкторов, было бы предпочтительно, чтобы поля всегда устанавливались одинаково - поэтому у вас могут быть такие векторы, как: 

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

edit: в качестве дополнительного комментария, обратите внимание, что в приведенном выше примере, если есть другие поля (не показаны) с инициализаторами полей, то они непосредственно инициализируются только в конструкторах, которые вызывают base (...) - т.е. публичная строка (строка foo) ctor. Другой конструктор не запускает инициализаторы полей, поскольку знает, что они выполняются ctor this (...) .

Другие советы

На самом деле, инициализаторы полей, как вы демонстрируете, являются удобным сокращением. Компилятор фактически копирует код инициализации в начало каждого конструктора экземпляра, который вы определяете для своего типа.

Это имеет два значения: во-первых, любой код инициализации поля дублируется в каждом конструкторе, а во-вторых, любой код, который вы включаете в ваши конструкторы для инициализации полей с конкретными значениями, фактически переназначает поля.

Таким образом, с точки зрения производительности и с точки зрения размера скомпилированного кода, вам лучше переместить инициализаторы полей в конструкторы.

С другой стороны, влияние на производительность и «раздувание» кода, как правило, пренебрежимо мало, и синтаксис инициализатора поля имеет важное преимущество, заключающееся в уменьшении риска того, что вы можете забыть инициализировать какое-либо поле в одном из ваших конструкторов.

Одним из основных ограничений инициализаторов полей является отсутствие возможности обернуть их в блок try-finally.Если в инициализаторе поля создается исключение, все ресурсы, выделенные предыдущими инициализаторами, будут отменены;нет способа предотвратить это.С другими ошибками в построении можно справиться, хотя это и неуклюже, если конструктор защищенной базы примет IDisposable по ссылке и укажет его на себя в качестве своей самой первой операции.Тогда можно избежать вызова конструктора, за исключением фабричных методов, которые в случае исключения будут вызывать Dispose для частично созданного объекта.Эта защита позволит очистить IDisposables, созданные в инициализаторах производного класса, если конструктор основного класса завершится сбоем после «контрабандного вывоза» ссылки на новый объект.К сожалению, невозможно обеспечить такую ​​защиту в случае сбоя инициализатора поля.

Используйте либо инициализаторы полей, либо создайте функцию Init (). Проблема с размещением этих вещей в вашем конструкторе заключается в том, что если вам когда-нибудь понадобится добавить 2-й конструктор, вы в конечном итоге получите код для копирования / вставки (или пропустите его и получите неинициализированные переменные).

Я бы либо инициализировал, где объявлено. Или пусть конструктор (ы) вызовет функцию Init ().

Для переменных экземпляра это в основном вопрос стиля (я предпочитаю использовать конструктор). Для статических переменных существует повышение производительности для инициализация inline (не всегда возможно, конечно).

Это действительно зависит от вас.
Я часто инициализирую их встроенными, потому что мне не нравится иметь конструктор, когда он мне действительно не нужен (мне нравятся маленькие классы!).

В добавок к вышесказанному - у вас всегда есть конструктор при реализации классов, которые имеют реализацию. Если вы не объявите его, инструктор по умолчанию будет выведен компилятором [public Foo () {}]; конструктор, который не принимает аргументов.

Часто мне нравится предлагать оба подхода. Разрешите конструкторы для тех, кто хочет их использовать, и разрешите инициализаторы полей для ситуаций, когда вы хотите использовать упрощенную или стандартную реализацию вашего класса / типа. Это добавляет гибкости вашему коду. Имейте в виду, что любой может использовать инициализатор поля по умолчанию, если он выберет ... Обязательно объявите его вручную, если вы предлагаете более одного конструктора - public Foo () {}

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top