Чи слід віддати перевагу властивостям із приватними полями чи без них?

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

// 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;
        }
    }
}

В: Ваші геттери / сетери мають будь-яку логіку. Код 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. Під час налагодження ви не можете поставити точку перерви методом get або set AIP, тому ви не зможете легко визначити, коли програма отримує або встановлює це властивість. Ви можете встановити точки перерви на точки вбивства, реалізовані вручну

Чи є вагомі причини віддати перевагу старішому, більш чіткому стилю перед новим, більш стислим?

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

Чи слід писати якісь нові класи, використовуючи стислий стиль, чи намагатись відповідати старішому коду за послідовністю? Чи достатньо в цьому випадку послідовності, щоб виправдати старіший формат?

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