인터페이스가 다른 인터페이스를 구현하는 이유는 무엇입니까?

Question

나는 List<T>이라는 선언문을보고 IList<T>, ICollection<T> 및 IEnumerable<T>을 구현한다는 것을 알았다.

그런 다음 나는 IList<T>의 정의를 보러 가서 ICollection<T>과 IEnumerable<T>을 구현하는 것을 보았습니다.

"계약서"처럼 작동하고 다른 인터페이스를 구현하는 인터페이스의 점은 무엇이며 코드를 쓰지 않으십니까?

이 구현은 누적됩니까? 그렇다면 IList<T>은 ICollection<T>과 IEnumerable<T>을 구현하므로 List<T>은 IList<T>을 구현하지 않아야하나요?

죄송합니다. 제 질문이 혼란 스럽다면, 지금 당황 스럽습니다.

Answer 1

다른 인터페이스를 구현하는 인터페이스는 "계약서"처럼 작동하며 실제 코드를 쓰지 않습니다.

인터페이스는 클래스와 동일한 방식으로 상속을 지원하고 다형성을 촉진합니다. IList<T>도 이며, TextBox이 Control 인 것과 같습니다.

이 구현은 누적됩니까? 그렇다면 IList가 ICollection 및 IEnumerable을 구현하므로 List에 IList 만 구현하면 안됩니까?

다른 사람들도 지적했듯이, 이는 대부분 가독성과 유지 보수성을위한 것입니다. 예, 상속은 누적됩니다. 그러나 클래스가 동일한 서명을 가진 멤버를 포함하는 여러 인터페이스를 구현할 때 모든 구현에 대해 하나의 멤버 만 정의하면됩니다. Explicit interface implementation은 주어진 구현에 대한 멤버를 명시 적으로 정의하는 데 사용될 수 있습니다.

Answer 2

최소한 중복을 줄입니다.

public interface INamedObject { string Name { get; } } 
public interface IValuedObject<T> { T Value { get; } } 
public interface INamedValuedObject<T> : INamedObject, IValuedObject<T> { } 

는보다 나은 디자인 :

이

public interface INamedObject { string Name { get; } } 
public interface IValuedObject<T> { T Value { get; } } 
public interface INamedValuedObject<T> { 
    string Name { get; } 
    T Value { get; } 
} 

는 또한, 후자의 경우에서, INamedValuedObject<T> 지금 통지도 INamedObject도 아니고 IValuedObject<T>.

"INamedValuedObject<T>은 INamedObject, IValuedObject<T>이며 다음 요소가있는 것"으로 읽을 수 있습니다. "