Explizites Implementieren von Schnittstellenmembern
Aktualisiert: November 2007
Eine Schnittstelle ist ein Vertrag für die Unterstützung von Funktionalität. Klassen, die eine Schnittstelle implementieren, müssen die Implementierungsdetails für die in der Schnittstelle angegebenen Member bereitstellen. Beispielsweise definiert die IEnumerator-Schnittstelle die Membersignaturen, die implementiert werden müssen, um das Auflisten eines Satzes von Objekten, z. B. einer Auflistung, zu unterstützen. Zum Implementieren von IEnumerator muss eine Klasse die Member Current, MoveNext und Reset implementieren.
Wenn ein Schnittstellenmember explizit von einer Klasse implementiert wird, kann auf den Member nur über einen Verweis auf die Schnittstelle zugegriffen werden. Dies bewirkt, dass der Schnittstellenmember verdeckt wird. Häufig werden Schnittstellenmember nicht nur explizit implementiert, um den Vertrag der Schnittstelle einzuhalten, sondern auch, um die Schnittstelle zu optimieren (um z. B. stark typisierte Methoden bereitzustellen, die anstelle der schwach typisierten Methoden der Schnittstelle verwendet werden sollen). Schnittstellenmember werden auch häufig explizit implementiert, wenn explizite Schnittstellenmember nicht von Entwicklern aufgerufen werden sollen. Beispielsweise wird der GetObjectData-Member sehr häufig explizit implementiert, weil er von der Serialisierungsinfrastruktur aufgerufen wird und nicht von Code aufgerufen werden soll.
Anhand der folgenden Entwurfsrichtlinien können Sie sicherstellen, dass im Bibliotheksentwurf eine explizite Schnittstellenimplementierung nur verwendet wird, wenn dies angebracht ist.
Implementieren Sie Schnittstellenmember nur explizit, wenn starke Gründe dafürsprechen.
Das Verständnis expliziter Implementierung erfordert fortgeschrittene Kenntnisse. Beispielsweise wissen viele Entwickler nicht, dass ein explizit implementierter Member öffentlich aufgerufen werden kann, obwohl seine Signatur privat ist. Daher sind explizit implementierte Member nicht in der Liste öffentlich sichtbarer Member vorhanden. Das explizite Implementieren eines Members kann außerdem unnötiges Boxing von Werttypen verursachen.
Implementieren Sie Schnittstellenmember explizit, wenn die Member nur über die Schnittstelle aufgerufen werden sollen.
Dies betrifft hauptsächlich Member, die die .NET Framework-Infrastruktur, z. B. Datenbindung oder Serialisierung, unterstützen. Beispielsweise soll aufdieIsReadOnly-Eigenschaft nur durch die Datenbindungsinfrastruktur mithilfe eines Verweises auf die ICollection<T>-Schnittstelle zugegriffen werden. Die List<T>-Klasse implementiert die Eigenschaft explizit, da sie dieser Richtlinie entspricht.
Implementieren Sie Schnittstellenmember explizit, um Varianz (d. h. das Ändern von Parametern oder des Rückgabetyps in überschriebenen Membern) zu simulieren.
Dies geschieht häufig, um stark typisierte Versionen der Schnittstellenmember bereitzustellen.
Implementieren Sie Schnittstellenmember explizit, um einen Member zu verdecken und einen entsprechenden Member mit einem besseren Namen hinzuzufügen.
Hierdurch wird ein Member effizient umbenannt. Beispielsweise implementiert StreamDispose explizit und stellt stattdessen die Close-Methode bereit.
Verwenden Sie explizite Member nicht als Sicherheitsgrenze.
Das explizite Implementieren eines Members bietet keine zusätzliche Sicherheit. Diese Member können über einen Verweis auf die Schnittstelle öffentlich aufgerufen werden.
Stellen Sie einen geschützten virtuellen Member bereit, der dieselbe Funktionalität wie der explizit implementierte Member bietet, wenn die Funktionalität von abgeleiteten Klassen auf spezielle Funktionen eingeschränkt werden soll.
Explizit implementierte Member können nicht überschrieben werden. Wenn sie in einer abgeleiteten Klasse neu definiert werden, kann die abgeleitete Klasse die Basisklassenimplementierung nicht aufrufen. Verwenden Sie für den Namen des geschützten Members denselben Namen wie für den expliziten Schnittstellenmember, oder fügen Sie dem Namen des Schnittstellenmembers Core hinzu.
Copyright für einzelne Teile 2005 Microsoft Corporation. Alle Rechte vorbehalten.
Copyright für einzelne Teile Addison-Wesley Corporation. Alle Rechte vorbehalten.
Weitere Informationen zu Entwurfsrichtlinien finden Sie im Buch "Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries" von Krzysztof Cwalina und Brad Abrams, veröffentlicht von Addison-Wesley, 2005.