Повторная реализация интерфейса, который уже унаследован другим интерфейсом
Я часто вижу такие вещи:
interface A { ... }
interface B : A { ... }
class C : B, A { ...}
Зачем указывать, что C реализует интерфейс A, если B уже наследует A? Имеет ли это какое-то значение семантической разницы или это просто вопрос стиля?
(Одним из многих примеров является List<T>, реализующий IList<T> и ICollection<T>, в то время как IList<T> также является производным от ICollection<T>).
Обновлять: Спасибо, что подтвердили мою догадку, что это не имеет никакого смысла.
Я придумал связанную ситуацию, когда делает имеет значение, чтобы явно указать интерфейс, который уже находится в дереве наследования:
Если бы B был классом, C только (повторно) реализовал бы элементы интерфейса из A, если бы он назвал A явно после «:».
[EDIT] Я изменил формулировку вопроса, чтобы избежать путаницы с явно реализованными элементами интерфейса, которые ограничивают использование члена случаями, когда объект приводится как интерфейс.
Ответы 1
Я считаю, что это просто вопрос стиля. Это особенно важно при рассмотрении классов фреймворка / библиотеки - в вашем примере, например, он подчеркивает идею о том, что этот класс можно рассматривать как ICollection или IList, при этом разработчик не должен знать, что IList на самом деле является ICollection.
Не имеет функциональных разветвлений. В частности, этот код будет компилироваться независимо от того, класс 'C' явно реализует 'A':
namespace DotNetInterfaceTest {
class Program {
static void Main(string[] args) {
A c = new C();
}
}
interface A {
void foo();
}
interface B : A {
void bar();
}
class C : B {
public void bar() {}
public void foo() {}
}
}
Я думаю, это для лучшей читаемости ... без необходимости работать с клетками вашего мозга, пересекающими иерархию наследования интерфейсов.