2010-08-27 34 views
8

Nếu tôi đặt thành viên nhóm là riêng tư và sau đó tôi muốn thành viên đó, chúng tôi phải xác định thuộc tính công khai cho thành viên đó. Nhưng sau đó tôi tự hỏi: Nếu chúng ta có thể sử dụng công khai thành viên lớp học bằng cách tuyên bố một thuộc tính công khai cho nó, thì tại sao chúng ta không chỉ định nghĩa thành viên lớp là công khai?Tại sao lại sử dụng các thuộc tính công khai cho các trường riêng trong C#?

+2

bạn đang hỏi gì? Điều đó (một câu) là không thể giải mã được. – tster

+0

Tôi đã chỉnh sửa nó rất nhiều. Tôi nghĩ đây là ý của anh ấy. – Timwi

+0

Tôi nghĩ câu cuối cùng "... là tư nhân ở nơi đầu tiên" nên được thay đổi thành "... là công khai lúc đầu". –

Trả lời

2

Vì bạn có thể xác thực giá trị được chỉ định trong thuộc tính.

+0

Đây không thực sự là một đối số bởi vì nếu sau này bạn thấy cần phải làm điều này, bạn có thể * vẫn * giới thiệu thuộc tính sau đó. – Timwi

+0

@Timwi, tôi nghĩ rằng việc thay đổi thành viên sang thuộc tính sẽ buộc mã sử dụng loại trong một .dll để biên dịch lại. Mặc dù đây không phải là vấn đề đối với hầu hết mọi người, nếu bạn đang phân phối .dll để sử dụng cho bên thứ 3, điều này cần tránh. – tster

+0

Có, nhưng như bạn đã chỉ ra, nó chỉ áp dụng cho các thư viện. Câu trả lời của bạn không tuyên bố điều đó. – Timwi

0

Trình truy cập thuộc tính (phương thức nhận, đặt) cho phép bạn thay đổi triển khai của mình là tương lai. Ví dụ, bạn có thể bắt đầu với một trường sao lưu (thành viên lớp riêng) nhưng sau đó thuộc tính có thể trở thành kết quả của một số phép tính. Hơn nữa, cú pháp thuộc tính cho phép bạn có các thành viên chỉ đọc - vì vậy bạn có thể thay đổi giá trị chỉ bên trong lớp của bạn, thế giới bên ngoài chỉ có thể đọc nó.

+1

Đối số này làm cho trường hợp cho thuộc tính chỉ đọc - nhưng không đọc/ghi. Nếu sau này bạn tìm thấy sự cần thiết cho một tài sản vì nó biến thành một giá trị được tính toán, bạn vẫn có thể giới thiệu tài sản sau đó. – Timwi

13

Microsoft khuyên bạn nên sử dụng các thuộc tính công cộng thay cho các trường công cộng vì lý do khả năng tương thích nhị phân. Đây chỉ là vấn đề nếu bạn đang viết một thư viện (mà các chương trình khác sẽ truy cập).

Về cơ bản, hãy tưởng tượng kịch bản này:

  • Bạn tạo một thư viện với một lĩnh vực công
  • người khác viết một chương trình sử dụng thư viện của bạn và truy cập mà lĩnh vực công cộng
  • Bây giờ bạn muốn thay đổi trường của bạn thành một thuộc tính công khai vì bạn cần xác thực giá trị đầu vào hoặc thuộc tính đã trở thành kết quả của phép tính hoặc bạn muốn nó ném ngoại lệ vì nó quá cũ hoặc bất kỳ điều gì.
  • Người dùng cố nâng cấp thư viện của bạn, chứ không phải chương trình sử dụng thư viện.

Điều này sẽ phá vỡ hoàn toàn chương trình - chương trình sẽ ngừng hoạt động và chỉ bị lỗi. Tuy nhiên, nếu thay vì trường bạn đã có quyền sở hữu công khai ngay từ đầu thì bạn có thể trao đổi thư viện.

Điều này tất nhiên chỉ phù hợp với thư viện. Trong tất cả các trường hợp khác, lời khuyên không thực sự có liên quan và bạn có thể sử dụng các trường nếu bạn muốn. Nếu sau đó bạn thấy rằng bạn cần một tài sản, bạn vẫn có thể thay đổi nó thành một thuộc tính sau đó và chương trình của bạn vẫn sẽ biên dịch tốt.

+1

Giải thích rất hay. – Hari

0

Dưới đây là một số lý do tại sao chúng tôi sử dụng các thuộc tính công khai thay vì các trường công khai.

  1. Bạn có thể viết mã phức tạp hơn trong phương thức get/set, trong khi chỉ có một giá trị duy nhất trong trường.
  2. Thuộc tính tạo mã của bạn nhiều hơn "OO". Nói một lớp có tên là Person, chúng tôi có thể dễ dàng đoán rằng có một thuộc tính được gọi là "Tên" trong đó. Nhưng một trường công khai có tên là "Tên" là thực sự là lạ.
  3. Một số thuộc tính chỉ hoạt động cho các thuộc tính chỉ (AttributeTargets.Property).
0

Lý do sử dụng các thuộc tính rất đơn giản. Bạn luôn có thể thay đổi xử lý mã nhận/đặt giá trị của nó mà không vi phạm bất kỳ chương trình bên ngoài nào tùy thuộc vào công việc của bạn - điều này là không thể với các trường.Hơn nữa, các thuộc tính có thể được đánh dấu là ảo, và do đó, có thể được định nghĩa lại bởi các lớp con - một lần nữa mà không vi phạm bất kỳ khả năng tương thích nào.

Các vấn đề liên quan