Почему мы используем пустые get; set; accessors в C#? [дубликат]

он инкапсулирует сгенерированное компилятором поле и предоставляет вам class или struct разработчик возможность обновить его внутри позже, не нарушая API, просто изменив get/set часть, о которой вы заботитесь.

например, внезапно никогда не хотите вернуться null? Вы можете сделать это, просто изменив пустой get to get { return storedName ?? ""; }. Конечно, это означает, что вам внезапно нужно вручную управлять переменной, но это небольшая цена за гибкость.

первый использовать пример поле декларации. Второй использовать пример автоматически реализуемое свойство.

это вообще плохая практика, чтобы обеспечить прямой доступ к полю. Тем не менее, команда .NET заметила, что многие геттеры/сеттеры в основном именно это. Например, рассмотрим следующее:

// C#
public string Name
{
    get { return name; }
    set { name = value; }
}

// Without properties (or a Java implementation)
public void setName(String name)
{
    this.name = name;
}

public String getName()
{
    return name;
}

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

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

рассмотрим следующий пример:

public string Name
{
    get;
    set;
}

позже вы решите, что вам нужно поднять изменение и измененное событие вокруг сеттера. Если вы выставили поле, то пришло время для потенциально большой перезаписи. Если вы использовали свойства (или метод), то вы можете просто добавить туда логику. Вы внезапно теряете преимущество свойств автоматической реализации, но получаете возможность рефакторинга своего класса без нарушения существующего кода.

private string name;
public event NameChangingEventHandler NameChanging;
public event NameChangedEventHandler NameChanged;

public string Name
{
    get { return name; }
    set
    {
        OnNameChanging(/*...*/);
        name = value;
        OnNameChanged(/*...*/);
    }
}

protected virtual void OnNameChanging(/*...*/) { }
protected virtual void OnNameChanged(/*...*/) { }

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

(несвязанный: потерял мощность при вводе этого, и я очень рад, что мой браузер сохранил большую часть!)