Nhược điểm của việc sử dụng các thuộc tính chỉ không có trường tương ứng trong .NET?

Question

Tôi có các lớp học có các thuộc tính tự động giống như tên khách hàng công cộng {get; bộ;}. Chúng được công khai vì chúng được truy cập bên ngoài lớp học. Họ cũng có thể được truy cập bên trong lớp học. Họ cung cấp đóng gói tốt và gỡ lỗi tốt hơn. Tôi có thể đặt một điểm dừng trên một nếu tôi cần biết ai đang truy cập nó và khi nào.

Câu hỏi của tôi là những nhược điểm khi sử dụng các thuộc tính chỉ với trường không tương ứng là gì? Tôi có thể làm cho setter hoặc getter tư nhân, nội bộ .. vv có nghĩa là tôi cũng có tính linh hoạt của phạm vi nó khi cần thiết.

Answer 1

Serialization với BinaryFormatter - bạn có vấn đề lớn nếu bạn cần phải thay đổi thuộc tính của bạn vào một tài sản "thường xuyên" sau đó, ví dụ như thêm một số xác nhận/eventing/etc - sinc BinaryFormatter sử dụng các tên trường. Và bạn không thể nhân đôi điều này, vì tên trường mà trình biên dịch tạo ra không thể được viết là hợp pháp C#.

Đó là lý do chính đáng để xem trình nối tiếp dựa trên hợp đồng thay thế. Xem this blog entry để biết thêm thông tin.

Answer 2

Không có bất lợi nào đối với các thuộc tính đơn giản. Trình biên dịch tạo ra trường sao lưu cho bạn. Điều này blog entry giải thích cách trình biên dịch xử lý tự động thực hiện các thuộc tính.

Answer 3

Vấn đề là, có là trường tương ứng. Bạn chỉ không nhìn thấy nó bởi vì trình biên dịch tạo ra nó cho bạn. Tính chất tự động chỉ là cú pháp đường hoặc cách viết tắt để tạo ra trường.

Answer 4

Bạn không thể tạo thực sự chỉ đọc thuộc tính, bởi vì bạn phải xác định cả setter và getter. Bạn chỉ có thể sử dụng setter riêng để đạt được thuộc tính giả đọc từ bên ngoài.

Nếu không, như đã nói ở trên không có bất lợi nào khác.

Answer 5

Không có điều gì lớn. Chỉ các trường hợp cạnh như nơi bạn cần chuyển thuộc tính sang phương thức mà tham số được truyền theo tham chiếu (ref hoặc out) không thể có thuộc tính (vì nội bộ, chúng chỉ là phương thức get_Property/set_Property được trình biên dịch triển khai , không phải lĩnh vực đặc biệt của một số loại) và bạn sẽ cần một lĩnh vực sao lưu riêng tư rõ ràng cho việc này.

CHỈNH SỬA: Ồ, và phân bổ thuộc tính 'no readonly', thực tế là khá phổ biến.

Answer 6

Nếu bạn không cần phải thực hiện bất kỳ logic cụ thể trong get và/hoặc thiết accessors, không có thiệt thòi ...

Answer 7

tôi nói rằng họ là xấu từ một quan điểm code dễ đọc. Đường cú pháp là tốt đẹp để viết mã nhưng khủng khiếp cho việc đọc mã. Khi các nhà phát triển, mã mà chúng tôi để lại phía sau cuối cùng sẽ được thừa kế bởi một số nhà phát triển kém, điều đó sẽ có ý nghĩa với những gì chúng tôi đã làm và những gì đang diễn ra trong mã. Tôi thực sự chống lại việc thay đổi một ngôn ngữ để chỉ đơn giản là tiết kiệm tổ hợp phím khi có một cú pháp được thiết lập cho cùng một cấu trúc.

Answer 8

Không thực sự là một bất lợi, nhưng bạn phải nhận thức được giá trị mặc định của thuộc tính tự động. Với các thuộc tính "cổ điển", chúng tôi luôn sử dụng để khởi tạo trường sao lưu, ví dụ: như thế này:

private bool _flag = true; 
public bool Flag 
{ 
    get { return _flag; } 
    set { _flag = value; } 
} 

Điều này làm cho giá trị mặc định của thuộc tính là rõ ràng.

Với thuộc tính tự động, bạn phải biết giá trị mặc định là gì cho các loại khác nhau (ví dụ: giả cho bool). Nếu bạn không muốn tài sản có giá trị mặc định, bạn phải khởi tạo nó trong các nhà xây dựng:

class MyClass 
{ 
    public bool Flag { get; set; } 
    public MyClass() 
    { 
    Flag = true; 
    } 
} 

Điều này có nghĩa, bạn phải thực hiện một constructor nếu bạn muốn khởi tạo thuộc tính của mình thành không mặc định giá trị hoặc nếu thuộc tính thuộc loại tham chiếu (lớp).

Nhưng như tôi đã viết, tôi không thực sự nghĩ rằng đây là một bất lợi, chỉ cần một cái gì đó bạn phải biết.