Re-Implementierung einer Schnittstelle, die eine andere Schnittstelle bereits erbt

Question

Ich sehe Sachen wie diese eine Menge:

interface A { ... }
interface B : A { ... }
class C : B, A { ...}

Warum sollten Sie festlegen, dass C-Schnittstelle A implementiert, wenn B bereits A erbt? Macht es einen semantischen Unterschied macht oder ist es nur eine Frage des Stils?

(Eines von vielen Beispielen ist List<T> Umsetzung IList<T> und ICollection<T>, während IList<T> ergibt sich auch aus ICollection<T>).

---

Update:. Dank für meine Vermutung bestätigt, dass es keinen semantischen Unterschied macht

Ich habe mit einer verwandten Situation kommen, wo es hat einen Unterschied machen explizit eine Schnittstelle zu nennen, die bereits im Vererbungsbaum ist:

Wenn B eine Klasse ist, C würde nur (Wieder-) -Schnittstelle Mitglieder aus A implementieren, wenn sie Namen A ausdrücklich nach dem ‚:‘.

[EDIT] ich den Wortlaut der Frage geändert um Verwechslungen zu vermeiden, explizit implementierte Schnittstelle Mitglieder, die die Verwendung des Elements auf die Fälle, in denen das Objekt als Schnittstelle umgewandelt wird.

Answer 1

Ich glaube, das ist nur eine Frage des Stils ist. Es ist besonders wichtig, wenn im Rahmen / Bibliotheksklassen suchen - in Ihrem Beispiel, zum Beispiel, es unterstreicht die Idee, dass diese Klasse entweder als ein ICollection behandelt werden kann oder eine IList, ohne dass die Entwickler mit wissen, dass IList tatsächlich ein ICollection ist.

Es hat keine funktionellen Auswirkungen. Insbesondere würde dieser Code kompilieren, ob oder nicht Klasse 'C' implementiert 'A' ausdrücklich:

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() {}
    }
}