Tôi nên thích các thuộc tính có hoặc không có các lĩnh vực tư nhân?

Cơ sở mã hiện đang làm việc có quy ước sử dụng các trường riêng và thuộc tính công cộng. Ví dụ, hầu hết các lớp có các thành viên được định nghĩa như thế này:

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

Tôi biết những thứ này có thể được viết lại mà không có thuộc tính riêng tư bên trong của chúng:

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

Tôi muốn một số đầu vào về điều này:

• Có một lý do chính đáng để thích phong cách cũ hơn, rõ ràng hơn so với phong cách mới hơn, súc tích hơn?
• Tôi nên viết bất kỳ lớp mới nào bằng cách sử dụng kiểu súc tích, hay tôi nên cố gắng khớp mã cũ hơn để thống nhất? Là sự nhất quán có đủ giá trị trong trường hợp này để biện minh cho định dạng cũ hơn?

Có một vài trường hợp vẫn yêu cầu kiểu "cũ" hơn:

A: Các loại bất biến sử dụng tính bất biến do ngôn ngữ cung cấp. Công cụ readonlysửa đổi trong C # đóng băng giá trị đó sau khi xây dựng. Không có cách nào để bắt chước điều này với các thuộc tính được triển khai tự động (chưa).

public sealed class FooBarBazInator
{
    private readonly double foo;

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

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

B: Getters / setters của bạn có bất kỳ logic nào. Mã WPF và Silverlight (và tương tự) được liên kết dữ liệu với các lớp của bạn sẽ triển khai INotifyPropertyChangednhư vậy:

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

Khác với những người khác, tôi muốn nói sử dụng phong cách mới. Giữ cho mã của bạn ngắn gọn và cung cấp ít diện tích bề mặt hơn cho các lỗi phát sinh. Ngoài ra, nếu cần thay đổi để bao gồm logic, nó sẽ không tương thích với chữ ký.

Tôi sẽ nói rằng có trường sao lưu rõ ràng chỉ là vô ích: nó làm cho mã của bạn dài hơn và khó đọc hơn. Nó cũng thêm tiềm năng lỗi:

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

Tôi nghĩ rằng một lỗi như thế này có thể xảy ra khá dễ dàng và sẽ khá khó để phát hiện ra.

Và nếu bạn muốn tính nhất quán, hãy làm theo cách khác: thay đổi mã sử dụng các trường sao lưu thành mã sử dụng các thuộc tính tự động. Điều này đặc biệt dễ dàng nếu bạn sử dụng một công cụ tái cấu trúc như ReSharper (và nếu bạn không sử dụng thứ gì đó tương tự, tôi nghĩ bạn nên bắt đầu).

Tất nhiên, vẫn có trường hợp cần có trường sao lưu là cần thiết, nhưng tôi nghĩ điều đó không liên quan đến câu hỏi này.

Mặc dù câu hỏi khá cũ nhưng tôi đã nghĩ đến việc thêm vài điểm mà tôi đọc được từ một cuốn sách đáng nói ở đây.

1. Các công cụ tuần tự hóa thời gian chạy vẫn duy trì tên của tệp được gửi trong một luồng được tuần tự hóa. Tên của trường sao lưu cho thuộc tính được triển khai tự động (AIP) được xác định bởi trình biên dịch và nó thực sự có thể thay đổi tên của trường sao lưu này mỗi khi bạn biên dịch lại mã của mình, phủ nhận khả năng khử lưu trữ các thể hiện của bất kỳ loại nào có chứa AIP. Vì vậy, không sử dụng AIP với bất kỳ loại nào bạn định nối tiếp hoặc giải tuần tự hóa.

2. Khi gỡ lỗi, bạn không thể đặt điểm dừng trên phương thức nhận hoặc đặt AIP, do đó bạn không thể dễ dàng phát hiện khi ứng dụng nhận hoặc đặt thuộc tính này. Bạn có thể đặt điểm dừng trên điểm dừng được triển khai thủ công

Có một lý do chính đáng để thích phong cách cũ hơn, rõ ràng hơn so với phong cách mới hơn, súc tích hơn?

Không hẳn vậy. Mặc dù tôi sẽ lập luận rằng bất cứ khi nào bạn có một tài sản như thế, bạn nên sử dụng một lĩnh vực công cộng để bắt đầu.

Tôi nên viết bất kỳ lớp mới nào bằng cách sử dụng kiểu súc tích, hay tôi nên cố gắng khớp mã cũ hơn để thống nhất? Là sự nhất quán có đủ giá trị trong trường hợp này để biện minh cho định dạng cũ hơn?

Giả sử bạn bỏ qua lời khuyên ở trên và có thuộc tính thông qua, tôi sẽ không nhắm đến phong cách phù hợp. Lý tưởng nhất là bạn sẽ quay lại và cấu trúc lại kiểu cũ thành kiểu mới để phù hợp, nhưng cơ hội để mọi người đọc sai mã đó là mỏng.