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

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

// Fields
private double _foo;
private double _bar;
private double _baz;

// Properties
public double Foo
{
    get{ return _foo; }
    set{ _foo = value; }
}

public double Bar
{
    get{ return _bar; }
    set{ _bar = value; }
}

public double Baz
{
    get{ return _baz; }
}

Я знаю, что они могут быть переписаны без их внутренних частных свойств:

public double Foo{ get; set; }
public double Bar{ get; set; }
public double Baz{ get; private set; }

Я хотел бы некоторый вклад по этому вопросу:

• Есть ли веская причина предпочесть более старый, более явный стиль более новому, более лаконичному?
• Должен ли я написать какие-либо новые классы, используя сжатый стиль, или я должен попытаться сопоставить старый код для согласованности? Достаточна ли последовательность в этом случае, чтобы оправдать старый формат?

Есть пара случаев, когда так называемый «старый» стиль все еще необходим:

A: Неизменяемые типы, использующие неизменяемость языка. readonlyМодификатор в C # замерзает , что значение после строительства. Там нет способа имитировать это с автоматически реализованными свойствами (пока).

public sealed class FooBarBazInator
{
    private readonly double foo;

    public FooBarBazInator(double foo)
    {
        this.foo = foo;
    }

    public double Foo
    {
        get
        {
            return this.foo;
        }
    }
}

B: Ваши геттеры / сеттеры имеют какую-либо логику. Код WPF и Silverlight (и аналогичный), привязанный к данным для ваших классов, будет реализован INotifyPropertyChangedследующим образом:

public class FooBarBazInator : INotifyPropertyChanged
{
    private double foo;

    public event PropertyChangedEventHandler PropertyChanged;

    public double Foo
    {
        get
        {
            return this.foo;
        }

        set
        {
            this.foo = value;
            this.RaisePropertyChanged("Foo");
        }
    }

    private void RaisePropertyChanged(string propertyName)
    {
        var propertyChanged = this.PropertyChanged;

        if (propertyChanged != null)
        {
            propertyChanged(this, new PropertyChangedEventArgs(propertyName));
        }
    }
}

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

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

public double Bar
{
    get { return _baz; }
    set { _bar = value; }
}

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

А если вам нужна согласованность, сделайте это по-другому: измените код, который использует вспомогательные поля, на код, который использует автоматические свойства. Это особенно легко, если вы используете инструмент рефакторинга, такой как ReSharper (и если вы не используете что-то подобное, я думаю, вам следует начать).

Конечно, все еще есть случаи, когда наличие вспомогательного поля необходимо, но я думаю, что это не относится к этому вопросу.

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

1. Механизмы сериализации во время выполнения сохраняют имя файла в сериализованном потоке. Имя вспомогательного поля для Автоматически реализуемого свойства (AIP) определяется компилятором, и оно может фактически изменять имя этого вспомогательного поля каждый раз, когда вы перекомпилируете свой код, сводя на нет возможность десериализации экземпляров любых типов, которые содержат AIP. Поэтому не используйте AIP с любым типом, который вы собираетесь сериализовать или десериализовать.

2. При отладке вы не можете поставить точку останова на метод получения или установки AIP, поэтому вы не можете легко определить, когда приложение получает или устанавливает это свойство. Вы можете установить точки останова на вручную установленные точки останова

Есть ли веская причина предпочесть более старый, более явный стиль более новому, более лаконичному?

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

Должен ли я написать какие-либо новые классы, используя сжатый стиль, или я должен попытаться сопоставить старый код для согласованности? Достаточна ли последовательность в этом случае, чтобы оправдать старый формат?

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