Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Hinweis
Dieser Inhalt wird mit Genehmigung von Pearson Education, Inc. aus Framework Design Guidelines: Konventionen, Idiome und Muster für wiederverwendbare .NET-Bibliotheken, 2. Auflage nachgedruckt. Diese Ausgabe wurde 2008 veröffentlicht, und das Buch wurde seitdem in der dritten Ausgabe vollständig überarbeitet. Einige der Informationen auf dieser Seite sind möglicherweise veraltet.
Erweiterungsmethoden sind ein Sprachfeature, mit dem statische Methoden mithilfe der Instanzmethodenaufrufssyntax aufgerufen werden können. Diese Methoden müssen mindestens einen Parameter verwenden, der die Instanz darstellt, auf der die Methode ausgeführt werden soll.
Die Klasse, die solche Erweiterungsmethoden definiert, wird als "Sponsor"-Klasse bezeichnet und muss als statisch deklariert werden. Um Erweiterungsmethoden zu verwenden, muss der Namespace importiert werden, der die Sponsorklasse definiert.
❌ VERMEIDEN Sie frivole Erweiterungsmethoden, insbesondere für Typen, die Sie nicht besitzen.
Wenn Sie einen eigenen Quellcode eines Typs verwenden, sollten Sie stattdessen reguläre Instanzmethoden verwenden. Wenn Sie nichts besitzen und eine Methode hinzufügen möchten, gehen Sie sehr vorsichtig vor. Die liberale Verwendung von Erweiterungsmethoden hat das Potenzial, APIs von Typen zu überladen, die nicht für diese Methoden entwickelt wurden.
✔️ ERWÄGEN SIE die Verwendung von Erweiterungsmethoden in einem der folgenden Szenarien:
Um Hilfsfunktionen bereitzustellen, die für jede Implementierung einer Schnittstelle relevant sind, können diese Funktionen in Bezug auf die Kernschnittstelle geschrieben werden. Dies liegt daran, dass konkrete Implementierungen nicht andernfalls Schnittstellen zugewiesen werden können. Beispielsweise werden die
LINQ to ObjectsOperatoren als Erweiterungsmethoden für alle IEnumerable<T> Typen implementiert. Daher wird jedeIEnumerable<>Implementierung automatisch LINQ-aktiviert.Wenn eine Instanzmethode eine Abhängigkeit von einem bestimmten Typ einführen würde, eine solche Abhängigkeit würde jedoch abhängigkeitsverwaltungsregeln unterbrechen. Beispielsweise ist eine Abhängigkeit von String zu System.Uri wahrscheinlich nicht wünschenswert, und so wäre eine Instanzmethode von
String.ToUri(), dieSystem.Urizurückgibt, aus einer Abhängigkeitsverwaltungsperspektive der falsche Entwurf. Eine statische ErweiterungsmethodeUri.ToUri(this string str), die zurückgegeben wirdSystem.Uri, wäre ein viel besseres Design.
❌ VERMEIDEN Sie die Definition von Erweiterungsmethoden für System.Object.
VB-Benutzer können diese Methoden für Objektverweise nicht mithilfe der Syntax der Erweiterungsmethode aufrufen. VB unterstützt das Aufrufen solcher Methoden nicht, da in VB das Deklarieren eines Verweises als Object alle Methodenaufrufe dazu erzwingt, spät gebunden zu sein (tatsächlich aufgerufenes Element wird zur Laufzeit bestimmt), während Bindungen an Erweiterungsmethoden zur Kompilierungszeit (früh gebunden) bestimmt werden.
Beachten Sie, dass die Richtlinie für andere Sprachen gilt, in denen dasselbe Bindungsverhalten vorhanden ist oder wenn Erweiterungsmethoden nicht unterstützt werden.
❌ SETZEN Sie Erweiterungsmethoden NICHT in denselben Namensraum wie den erweiterten Typ, es sei denn, es dient dem Hinzufügen von Methoden zu Schnittstellen oder dem Abhängigkeitsmanagement.
❌ VERMEIDEN Sie die Definition von zwei oder mehr Erweiterungsmethoden mit derselben Signatur, auch wenn sie sich in verschiedenen Namespaces befinden.
✔️ ERWÄGEN Sie, Erweiterungsmethoden im selben Namespace wie der erweiterte Typ zu definieren, wenn der Typ eine Schnittstelle ist und ob die Erweiterungsmethoden in den meisten oder allen Fällen verwendet werden sollen.
❌ Definieren Sie KEINE Erweiterungsmethoden, die eine Funktion in Namespaces implementieren, die normalerweise mit anderen Merkmalen verbunden sind. Definieren Sie sie stattdessen im Namespace, der dem Feature zugeordnet ist, zu dem sie gehören.
❌ VERMEIDEN Sie die generische Benennung von Namespaces, die erweiterungsmethoden zugeordnet sind (z. B. "Erweiterungen"). Verwenden Sie stattdessen einen beschreibenden Namen (z. B. "Routing").
© Teile 2005, 2009 Microsoft Corporation. Alle Rechte vorbehalten.
Nachdruck mit Genehmigung von Pearson Education, Inc. aus Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2. Auflage von Krzysztof Cwalina und Brad Abrams, veröffentlicht am 22. Okt 2008 von Addison-Wesley Professional als Teil der Microsoft Windows Development Series.