Лучше ли использовать Enumerable.Empty‹T›() вместо нового List‹T›() для инициализации IEnumerable‹T›?

Я думаю, что большинство сообщений упустили главное. Даже если вы используете пустой массив или пустой список, это объекты, и они хранятся в памяти. Сборщик мусора должен позаботиться о них. Если вы имеете дело с приложением с высокой пропускной способностью, это может оказать заметное влияние.

Enumerable.Empty не создает объект для каждого вызова, что снижает нагрузку на сборщик мусора.

Если код находится в месте с низкой пропускной способностью, то это сводится к эстетическим соображениям.

Я думаю, что Enumerable.Empty<T> лучше, потому что он более явный: ваш код четко указывает на ваши намерения. Это также может быть немного более эффективным, но это лишь второстепенное преимущество.

Что касается производительности, давайте посмотрим, как реализован Enumerable.Empty<T>.

Он возвращает EmptyEnumerable<T>.Instance, который определяется как:

internal class EmptyEnumerable<T>
{
    public static readonly T[] Instance = new T[0];
}

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

А именно:

Debug.Assert(ReferenceEquals(Enumerable.Empty<int>(), Enumerable.Empty<int>()));

Предполагая, что вы действительно хотите каким-то образом заполнить свойство Roles, затем инкапсулируйте это, сделав его сеттер закрытым и инициализировав его новым списком в конструкторе:

public class Person
{
    public string Name { get; set; }
    public IList<Role> Roles { get; private set; }

    public Person()
    {
        Roles = new List<Role>();
    }
}

Если вы действительно хотите иметь общедоступный сеттер, оставьте Roles со значением null и избегайте выделения объекта.

Проблема с вашим подходом заключается в том, что вы не можете добавлять какие-либо элементы в коллекцию - у меня была бы частная структура, такая как список, а затем выставлять элементы как Enumerable:

public class Person
{
    private IList<Role> _roles;

    public Person()
    {
        this._roles = new List<Role>();
    }

    public string Name { get; set; }

    public void AddRole(Role role)
    {
        //implementation
    }

    public IEnumerable<Role> Roles
    {
        get { return this._roles.AsEnumerable(); }
    }
}

Если вы хотите, чтобы какой-то другой класс создал список ролей (что я бы не рекомендовал), то я бы вообще не инициализировал перечисляемое в Person.

Типичная проблема с представлением частного списка как IEnumerable заключается в том, что клиент вашего класса может возиться с ним путем приведения. Этот код будет работать:

  var p = new Person();
  List<Role> roles = p.Roles as List<Role>;
  roles.Add(Role.Admin);

Вы можете избежать этого, реализуя итератор:

public IEnumerable<Role> Roles {
  get {
    foreach (var role in mRoles)
      yield return role;
  }
}