Erweiterungsmethoden
Hinweis
Diese Inhalte wurden mit Genehmigung von Pearson Education, Inc. aus Framework Design Guidelines nachgedruckt: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition. 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 Aufrufsyntax für Instanzmethoden aufgerufen werden können. Diese Methoden müssen mindestens einen Parameter annehmen, der die Instanz darstellt, für die die Methode verwendet werden soll.
Die Klasse, die solche Erweiterungsmethoden definiert, wird als „Sponsorklasse“ bezeichnet und muss als statisch deklariert werden. Wenn Sie Erweiterungsmethoden verwenden möchten, müssen Sie den Namespace importieren, der die Sponsorklasse definiert.
❌ VERMEIDEN Sie es, leichtfertig Erweiterungsmethoden zu definieren, insbesondere für Typen, die nicht Ihr Eigentum sind.
Wenn Sie Quellcode eines Typs besitzen, sollten Sie erwägen, stattdessen reguläre Instanzmethoden zu verwenden. Wenn Sie nicht Besitzer sind und eine Methode hinzufügen möchten, gehen Sie sehr vorsichtig vor. Eine großzügige Verwendung von Erweiterungsmethoden kann dazu führen, dass APIs von Typen, die nicht für diese Methoden konzipiert wurden, unübersichtlich werden.
✔️ ERWÄHEN Sie in den folgenden Szenarien die Verwendung von Erweiterungsmethoden:
Bereitstellung von Hilfsfunktionen, die für jede Implementierung einer Schnittstelle relevant sind, wenn diese Funktionalität in Form der Kernschnittstelle geschrieben werden kann. Das liegt daran, dass konkrete Implementierungen sonst nicht den Schnittstellen zugeordnet werden können. Beispielsweise werden die
LINQ to Objects-Operatoren als Erweiterungsmethoden für alle IEnumerable<T>-Typen implementiert. Folglich ist jedeIEnumerable<>-Implementierung automatisch LINQ-aktiviert.Wenn eine Instanzmethode eine Abhängigkeit von einem Typ einführen würde, eine solche Abhängigkeit jedoch die Regeln für die Abhängigkeitsverwaltung verletzen würde. Zum Beispiel ist eine Abhängigkeit von String zu System.Uri wahrscheinlich nicht wünschenswert, und daher wäre die
String.ToUri()-Instanzmethode, dieSystem.Urizurückgibt, aus Sicht der Abhängigkeitsverwaltung der falsche Entwurf. Eine statische ErweiterungsmethodeUri.ToUri(this string str), dieSystem.Urizurückgibt, ist ein viel besserer Entwurf.
❌ VERMEIDEN Sie es, Erweiterungs Methoden für System.Object zu definieren.
VB-Benutzer sind nicht in der Lage, solche Methoden für Objektverweise mithilfe der Syntax der Erweiterungsmethode aufzurufen. VB unterstützt den Aufruf solcher Methoden nicht, weil in VB die Deklaration eines Verweises als Objekt dazu führt, dass alle seine Methodenaufrufe spät gebunden werden (der tatsächlich aufgerufene Member wird zur Laufzeit bestimmt), während Bindungen an Erweiterungsmethoden zur Kompilierzeit bestimmt werden (früh gebunden).
Beachten Sie, dass die Richtlinie auch für andere Sprachen gilt, in denen das gleiche Bindungsverhalten vorhanden ist oder in denen Erweiterungsmethoden nicht unterstützt werden.
❌ Fügen Sie KEINE Erweiterungsmethoden im gleichen Namespace wie der erweiterte Typ ein, es sei denn, es geht um das Hinzufügen von Methoden zu Schnittstellen oder um Abhängigkeitsverwaltung.
❌ VERMEIDEN Sie es, zwei oder mehr Erweiterungsmethoden mit der gleichen Signatur zu definieren, auch wenn sie sich in unterschiedlichen Namespaces befinden.
✔️ ERWÄGEN Sie das Definieren von Erweiterungsmethoden im gleichen Namespace wie der erweiterte Typ, wenn der Typ eine Schnittstelle ist und die Erweiterungsmethoden in den meisten oder allen Fällen verwendet werden sollen.
❌ Definieren Sie KEINE Erweiterungsmethoden, die eine Funktion in Namespaces implementieren, die normalerweise anderen Features zugeordnet sind. Definieren Sie sie stattdessen in dem Namespace, der der Funktion zugeordnet ist, der sie angehören.
❌ VERMEIDEN Sie die generische Benennung von Namespaces, die für Erweiterungsmethoden reserviert sind (z. B. „Extensions“). 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, 2nd Edition von Krzysztof Cwalina und Brad Abrams, veröffentlicht am 22. Oktober 2008 durch Addison-Wesley Professional als Teil der Microsoft Windows Development Series.