2011-12-15 40 views
32

Có ai vui lòng giúp tôi xem liệu thực tiễn tốt nhất có bao gồm các thuộc tính trên Giao diện hoặc Lớp Tóm tắt không?C# thuộc tính trên Giao diện

Tôi tưởng tượng một Giao diện chỉ nên có chữ ký phương thức?

+0

bản sao có thể có của [Giao diện vs Lớp trừu tượng (chung OO)] (http://stackoverflow.com/questions/761194/interface-vs-abstract-class-general-oo) – MPelletier

+2

làm thế nào là một bản dupe? Như Kyle đã chỉ ra bên dưới cả hai giao diện và các lớp trừu tượng có thể có các thuộc tính nên không có "so với" đây. – bryanmac

Trả lời

11

Thuộc tính cũng tốt trong một giao diện

Xem:

http://msdn.microsoft.com/en-us/library/ms173156.aspx

Giao diện bao gồm các phương pháp, tài sản, các sự kiện, bộ chỉ mục, hoặc bất kỳ sự kết hợp của những bốn loại thành viên. Giao diện không thể chứa hằng số, trường, toán tử, trình tạo mẫu, hàm hủy hoặc loại. Nó không thể chứa các thành viên tĩnh. Các thành viên giao diện là tự động công khai và chúng không thể bao gồm bất kỳ công cụ sửa đổi truy cập nào.

+20

Chỉ vì nó có thể không có nghĩa là nó là một thực hành tốt nhất khi OP hỏi. –

12

Hoàn toàn có thể chấp nhận được các thuộc tính trong giao diện. Tôi làm nó suốt.

+0

Có lẽ đó chỉ là một câu hỏi về sở thích. Vâng, tôi sẽ quên những cuộc tranh luận và làm như những gì bạn làm. – SWIIWII

6

Hoàn toàn hợp lệ để bao gồm thuộc tính trong giao diện hoặc lớp trừu tượng.

25

Thuộc tính là đường cú pháp cho phương pháp. Xem xét việc này:

tôi có một tài sản:

String PropertyA { get; set; } 

Khi chạy này trở thành một cái gì đó như thế này:

String get_PropertyA() { ... } 
void set_PropertyA(String value) { ... } 

Lưu ý rằng "..." cho biết rằng mã sẽ được đặt ở đó bởi trình tạo mã. Hiệu quả những gì tôi đang nói là các thuộc tính không thực sự tồn tại ngoài C#, khi chúng biên dịch xuống các phương thức bằng cách sử dụng một convetion được chỉ ra trong ví dụ của tôi. Để xác nhận điều tôi đang nói, bạn có thể sử dụng sự phản chiếu và xem xét mã phản chiếu trông như thế nào.

Tuy nhiên, có thể thực hành không tốt để đặt thuộc tính trên giao diện nếu chúng thực hiện điều gì đó không quan trọng trong quá trình triển khai. Ví dụ, nếu tôi muốn đặt một biến và cập nhật các biến khác, hoặc thiết lập một thuộc tính có thể từ chối việc gán thuộc tính của tôi vì một điều kiện bên trong, thì một thuộc tính không nên được sử dụng. Tôi nghĩ rằng đó là một quy tắc chung sẽ áp dụng ngoài giao diện.

+2

Làm điều gì đó không tầm thường là một thực hành không tốt đối với các giai đoạn bất động sản như bạn đã chỉ ra.Nó gây ra các vấn đề trong trình gỡ lỗi và không rõ ràng đối với người tiêu dùng của lớp mà công việc quan trọng sẽ được thực hiện. Đối với giao diện, bạn không thể xác định xem nó có tầm thường không vì nó không có triển khai. Tất cả những gì bạn có thể làm là ngụ ý công việc không tầm thường bằng tên - nhưng theo công việc định nghĩa. tự nhiên ngụ ý một phương pháp. – bryanmac

+1

Chỉ sử dụng các thuộc tính getter có ý nghĩa hoàn hảo cho các giao diện DTO. – mbx

+0

Làm thế nào để chúng tôi xác định không tầm thường? Tôi đã đấu vật với quyết định tạo một vài thành viên trên các thuộc tính hoặc phương thức giao diện của tôi. Trên một triển khai, nó sẽ là một tập hợp/nhận thẳng của một trường, nhưng trên một trường khác, nó sẽ cần phải thực hiện một biểu thức chính quy để trích xuất giá trị ra khỏi một thành viên của trường. Làm thế nào chúng ta có thể biết nếu nó sẽ không tầm thường nếu chúng ta chưa biết các triển khai khác nhau của giao diện? –

1

Tôi không tin rằng có thực tiễn tốt nhất cho việc này.

Thuộc tính (thực sự là phương pháp) được phép trên giao diện. Bất cứ điều gì nhiều hơn điều này chỉ là một ý kiến. Điều này bao gồm quan điểm của tôi về bất cứ điều gì nhiều hơn là một ý kiến.

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