Частный 'набор' в C# - имеющий проблему, переносящую мой мозг вокруг этого

По сути, это свойство readonly. Если бы оно было написано полностью (не как свойство auto), вы бы просто убрали сеттер.

Два одинаковых примера:

class Foo1
{
   public int Id { get; private set; }
   public Foo1()
   {
       Id = lastId ++;
   }
}

class Foo2
{
   private int _id;  // could be readonly 
   public int Id { get { return _id; } }
   public Foo2()
   {
       _id = lastId ++;
   }
}

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

В качестве простого примера; это дешевый способ создания «достаточно неизменяемого» объекта (для использования в потоках, состоянии и т. д.). Но также и везде, где клиенту просто не нужно назначать его, или нельзя доверять , чтобы назначить его (правильно).

Другим примером может быть список:

public List<Foo> Items {get;private set;}

, поскольку мы можем вызвать obj.Items.Add () и т. Д., Но мы редко назначаем obj.Items = ... . Однако этот пример омрачен необходимостью явной инициализации в конструкторе, и XmlSerializer ненавидит это - честно говоря, для списков, которые я в основном использую:

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

, который решает обе эти проблемы.

В качестве другого примера, противопоставление:

private readonly int foo;
public int Foo {get{return foo;}}

vs

private readonly int foo;
public int Foo {get{return foo;} private set {foo=value;}}

этот шаблон может быть полезен при сериализации, например, с DataContractSerializer (с добавлением некоторых атрибутов), поскольку многие сериализаторы по-прежнему будут искать частные аксессуары. Это избавляет нас от необходимости украшать наше внутреннее состояние ( foo ), но дает видимость конфиденциальности для набора .

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

Я видел, как это использовалось с дизайном:

public class whatever
{
    public string WhateverId { get; private set; }

    public static whatever Create(string whateverId)
    {
        return new whatever() { WhateverId = whateverId };
    }
}

Итак, вы создаете любой класс, но после его создания идентификатор не может быть изменен, потому что он может сломать то, что с ним связано.

частный набор просто дает простой синтаксис инициализатора, мне он нравится в некоторых сценариях.

Также можно использовать, если он изменяемый, но вам нужно управлять им при внесении изменений

public void SetWhateverId(string whateverId)
{
    DisconnectAllCurrentWhateverIdReferences();
    WhateverId = whateverId;
    ReconnectAllPreviousWhateverIdReferences();
}

Чтобы ответить на вопрос о распространенном сценарии, где это может быть использовано... В шаблоне MVP, если ваша Модель раскрывает некоторые свойства для вашего Ведущего, я бы написал

public string Bazinga { get; private set; }

Теперь, Модель может изменить это значение, но другие классы, которые его используют, не могут.

частный набор очень удобен для простых неизменяемых типов значений.

struct Point
{
    public int X { get; private set; }
    public int Y { get; private set; }
    public Point(int x, int y)
    {
        this = default(Point);
        X = x;
        Y = y;
    }
}

Это просто лень , возникающая из-за авто-свойств. До появления автоматических свойств люди реализовывали метод получения и опускали сеттер для свойств, предназначенных только для чтения.

public class Test
{
   private /*readonly*/ Type _thingy;
   public Type Thingy { get { return _thingy; } }
}

Надеюсь, C # 5 позволит вам создавать автоматические свойства только с помощью геттера - потому что этого хотят все. (Они также должны делать сеттеры только для чтения в auto-props, мне это очень нужно)

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