Có được phép sử dụng triển khai giao diện rõ ràng để ẩn các thành viên trong C # không?

Tôi hiểu cách làm việc với các giao diện và triển khai giao diện rõ ràng trong C #, nhưng tôi tự hỏi liệu nó có bị coi là hình thức xấu để che giấu một số thành viên không được sử dụng thường xuyên không. Ví dụ:

public interface IMyInterface
{
    int SomeValue { get; set; }
    int AnotherValue { get; set; }
    bool SomeFlag { get; set; }

    event EventHandler SomeValueChanged;
    event EventHandler AnotherValueChanged;
    event EventHandler SomeFlagChanged;
}

Tôi biết trước rằng các sự kiện, trong khi hữu ích, sẽ rất hiếm khi được sử dụng. Vì vậy, tôi nghĩ sẽ tốt hơn nếu giấu chúng khỏi một lớp triển khai thông qua triển khai rõ ràng để tránh sự lộn xộn của IntelliSense.

Vâng, nó thường là hình thức xấu.

Vì vậy, tôi nghĩ sẽ tốt hơn nếu giấu chúng khỏi một lớp triển khai thông qua triển khai rõ ràng để tránh sự lộn xộn của IntelliSense.

Nếu IntelliSense của bạn quá bừa bộn, lớp của bạn quá lớn. Nếu lớp học của bạn quá lớn, có thể bạn sẽ làm quá nhiều thứ và / hoặc được thiết kế kém.

Khắc phục sự cố của bạn, không phải là triệu chứng của bạn.

Sử dụng tính năng cho những gì nó được dự định. Giảm sự lộn xộn không gian tên không phải là một trong số đó.

Lý do hợp pháp không phải là về "che giấu" hoặc tổ chức, họ là để giải quyết sự mơ hồ và chuyên môn hóa. Nếu bạn triển khai hai giao diện xác định "Foo", ngữ nghĩa cho Foo có thể khác nhau. Thực sự không phải là một cách tốt hơn để giải quyết điều này ngoại trừ các giao diện rõ ràng. Cách khác là không cho phép thực hiện các giao diện chồng chéo hoặc tuyên bố rằng các giao diện không thể liên kết ngữ nghĩa (dù sao đây cũng chỉ là một khái niệm). Cả hai đều là lựa chọn thay thế nghèo nàn. Đôi khi thực tế hơn hẳn sự thanh lịch.

Một số tác giả / chuyên gia coi đó là một tính năng của một tính năng (các phương thức không thực sự là một phần của mô hình đối tượng của loại). Nhưng giống như tất cả các tính năng, ở đâu đó, ai đó cần nó.

Một lần nữa, tôi sẽ không sử dụng nó để ẩn hoặc tổ chức. Có nhiều cách để che giấu các thành viên khỏi intellisense.

[System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)]

Tôi có thể là một dấu hiệu của mã lộn xộn, nhưng đôi khi thế giới thực là lộn xộn. Một ví dụ từ .NET framework là ReadOnlyColection ẩn bộ setter đột biến [], Add and Set.

IE ReadOnlyCollection thực hiện IList <T>. Cũng xem câu hỏi của tôi với SO vài năm trước khi tôi suy nghĩ về điều này.

Đó là hình thức tốt để làm như vậy khi thành viên là vô nghĩa trong bối cảnh. Ví dụ: nếu bạn tạo một bộ sưu tập chỉ đọc thực hiện IList<T>bằng cách ủy quyền cho một đối tượng nội bộ _wrappedthì bạn có thể có một cái gì đó như:

public T this[int index]
{
  get
  {
     return _wrapped[index];
  }
}
T IList<T>.this[int index]
{
  get
  {
    return this[index];
  }
  set
  {
    throw new NotSupportedException("Collection is read-only.");
  }
}
public int Count
{
  get { return _wrapped.Count; }
}
bool ICollection<T>.IsReadOnly
{
  get
  {
    return true;
  }
}

Ở đây chúng tôi có bốn trường hợp khác nhau.

public T this[int index]được định nghĩa bởi lớp của chúng tôi chứ không phải giao diện, và do đó tất nhiên không phải là một triển khai rõ ràng, mặc dù lưu ý rằng nó xảy ra tương tự như đọc-ghi T this[int index]được xác định trong giao diện nhưng chỉ đọc.

T IList<T>.this[int index]là rõ ràng bởi vì một phần của nó (getter) được kết hợp hoàn hảo bởi thuộc tính ở trên và phần khác sẽ luôn ném ngoại lệ. Mặc dù quan trọng đối với ai đó truy cập một thể hiện của lớp này thông qua giao diện, nhưng việc ai đó sử dụng nó thông qua một biến của loại lớp là vô nghĩa.

Tương tự vì bool ICollection<T>.IsReadOnlyluôn luôn trả về đúng, nó hoàn toàn vô nghĩa đối với mã được viết theo kiểu của lớp, nhưng có thể rất quan trọng đối với việc sử dụng nó thông qua loại giao diện, và do đó chúng tôi triển khai nó một cách rõ ràng.

Ngược lại, public int Countkhông được triển khai rõ ràng bởi vì nó có khả năng có thể được sử dụng cho ai đó sử dụng một thể hiện thông qua loại của chính nó.

Nhưng với trường hợp "rất hiếm khi được sử dụng" của bạn, tôi thực sự sẽ nghiêng về việc không sử dụng một triển khai rõ ràng.

Trong các trường hợp tôi khuyên bạn nên sử dụng một triển khai rõ ràng, gọi phương thức thông qua một biến kiểu của lớp sẽ là một lỗi (cố gắng sử dụng trình thiết lập được lập chỉ mục) hoặc vô nghĩa (kiểm tra một giá trị sẽ luôn giống nhau) để ẩn họ đang bảo vệ người dùng khỏi mã lỗi hoặc tối ưu phụ. Điều đó khác biệt đáng kể với mã mà bạn nghĩ là hiếm khi được sử dụng. Vì vậy, tôi có thể cân nhắc sử dụng EditorBrowsablethuộc tính để che giấu thành viên khỏi intellisense, mặc dù tôi sẽ cảm thấy mệt mỏi; bộ não của mọi người đã có phần mềm riêng để lọc ra những gì họ không quan tâm.