명시 적 인터페이스 구현을 사용하여 C #에서 멤버를 숨길 수 있습니까?

C #에서 인터페이스 및 명시 적 인터페이스 구현을 사용하는 방법을 알고 있지만 자주 사용하지 않는 특정 멤버를 숨기는 것이 나쁜 형식으로 간주되는지 궁금합니다. 예를 들면 다음과 같습니다.

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

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

유용한 이벤트는 거의 사용되지 않을 것이라는 것을 미리 알고 있습니다. 따라서 IntelliSense 혼란을 피하기 위해 명시 적 구현을 ​​통해 구현 클래스에서 숨기는 것이 합리적이라고 생각했습니다.

예, 일반적으로 나쁜 형태입니다.

따라서 IntelliSense 혼란을 피하기 위해 명시 적 구현을 ​​통해 구현 클래스에서 숨기는 것이 합리적이라고 생각했습니다.

IntelliSense가 너무 복잡하면 수업이 너무 큽니다. 수업이 너무 크면 너무 많은 일을하거나 설계가 잘못되었을 수 있습니다.

증상이 아닌 문제를 해결하십시오.

의도 한 기능을 사용하십시오. 네임 스페이스 혼란을 줄이는 것은 그 중 하나가 아닙니다.

합법적 인 이유는 "숨김"이나 조직에 관한 것이 아니라 모호성을 해결하고 전문화해야합니다. "Foo"를 정의하는 두 개의 인터페이스를 구현하면 Foo의 의미가 다를 수 있습니다. 명시 적 인터페이스를 제외하고는 이것을 해결하는 더 좋은 방법은 아닙니다. 대안은 겹치는 인터페이스 구현을 허용하지 않거나 인터페이스가 시맨틱을 연관시킬 수 없음을 선언하는 것입니다 (어쨌든 개념적 일뿐입니다). 둘 다 나쁜 대안입니다. 때로는 실용성이 우아함을 능가합니다.

일부 작성자 / 전문가는이 기능을 기능의 핵심이라고 생각합니다 (메서드는 실제로 유형의 개체 모델의 일부가 아닙니다). 그러나 모든 기능과 마찬가지로 어딘가에 누군가가 필요합니다.

다시, 나는 그것을 숨기거나 조직하기 위해 사용 하지 않을 것 입니다. 인텔리전스에서 멤버를 숨기는 방법이 있습니다.

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

지저분한 코드의 징조 일 수도 있지만 실제 세계가 지저분한 경우가 있습니다. .NET 프레임 워크의 한 가지 예 는 변경 설정자 [], 추가 및 설정을 숨기는 ReadOnlyColection 입니다.

IE ReadOnlyCollection은 IList <T>를 구현합니다. 내가 이것을 숙고했을 때 몇 년 전에 SO에 대한 내 질문 을 참조하십시오 .

구성원이 상황에 무의미 할 때 그렇게하는 것이 좋습니다. 예를 들어 IList<T>내부 객체에 위임하여 구현 되는 읽기 전용 컬렉션을 만들면 _wrapped다음과 같은 내용이있을 수 있습니다.

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

여기 네 가지 사례가 있습니다.

public T this[int index] 는 인터페이스가 아닌 클래스에 의해 정의되므로 물론 명시 적으로 구현되지는 않습니다.하지만 읽기-쓰기와 유사하다는 점에 유의하십시오. T this[int index] 인터페이스에 정의 된 하지만 읽기 전용입니다.

T IList<T>.this[int index]그중 일부 (게터)가 위의 속성과 완벽하게 일치하기 때문에 명시 적이며 다른 부분은 항상 예외를 throw합니다. 인터페이스를 통해이 클래스의 인스턴스에 액세스하는 사람에게는 매우 중요하지만 클래스 유형의 변수를 통해 해당 클래스를 사용하는 사람에게는 무의미합니다.

마찬가지로 bool ICollection<T>.IsReadOnly 항상 true를 반환 클래스 유형에 대해 작성된 코드에는 전혀 의미가 없지만 인터페이스 유형을 통해 코드를 사용하는 것이 중요 할 수 있으므로 명시 적으로 구현해야합니다.

거꾸로, public int Count 자체 유형을 통해 인스턴스를 사용하는 사람에게 잠재적으로 사용될 수 있으므로 명시 적으로 구현되지 않습니다.

그러나 "매우 드물게 사용 된"사례의 경우, 명시 적 구현을 ​​사용하지 않는 것이 좋습니다.

클래스 유형의 변수를 통해 메소드를 호출하는 명시 적 구현을 ​​사용하는 것이 권장되는 경우 오류 (인덱스 세터 사용 시도) 또는 무의미 (항상 동일한 값 확인)가 숨겨져 있습니다. 버그가 있거나 최적화되지 않은 코드로부터 사용자를 보호하고 있습니다. 그것은 거의 사용 되지 않을 것이라고 생각하는 코드와 크게 다릅니다 . 이를 위해 EditorBrowsable속성을 사용하여 멤버를 인텔리전스에서 숨기는 것을 고려할 수도 있습니다 . 사람들의 뇌에는 이미 관심없는 것을 걸러 내기위한 자체 소프트웨어가 있습니다.