Was sind die Best Practices für die Verwendung von Erweiterungsmethoden in .Net?

Question

Ich habe gesehen, wie diese auf die unterschiedliche Weise verwendet wurden, und mir wurde vorgeworfen, sie falsch verwendet zu haben (obwohl ich sie in diesem Fall auf diese Weise verwendet habe, um a zu demonstrieren). Punkt).

Was sind Ihrer Meinung nach die besten Vorgehensweisen für den Einsatz von Erweiterungsmethoden?

Sollten Entwicklungsteams eine Bibliothek mit Erweiterungsmethoden erstellen und diese in verschiedenen Projekten bereitstellen?

Sollte es eine Sammlung gängiger Erweiterungsmethoden in Form eines Open-Source-Projekts geben?

Aktualisieren:haben beschlossen, eine organisationsweite Bibliothek für Erweiterungsmethoden zu erstellen

Answer 1

Die kommende Veröffentlichung der Framework Design Guidelines, 2. Auflage, wird einige Anleitungen zur Implementierung von Erweiterungsmethoden enthalten, aber im Allgemeinen:

Sie sollten Erweiterungsmethoden nur dort definieren, „wo sie semantisch sinnvoll sind“ und Hilfsfunktionen bereitstellen, die für jede Implementierung relevant sind.

Sie sollten außerdem vermeiden, System.Object zu erweitern, da nicht alle .NET-Sprachen die Erweiterungsmethode als Erweiterung aufrufen können.(VB.NET müsste es beispielsweise als reguläre statische Methode für die statische Erweiterungsklasse aufrufen.)

Definieren Sie keine Erweiterungsmethode im selben Namespace wie der erweiterte Typ, es sei denn, Sie erweitern eine Schnittstelle.

Definieren Sie keine Erweiterungsmethode mit derselben Signatur wie eine „echte“ Methode, da diese nie aufgerufen wird.

Answer 2

Vielleicht möchten Sie einen Blick darauf werfen http://www.codeplex.com/nxl Und http://www.codeplex.com/umbrella Bei beiden handelt es sich um Erweiterungsmethodenbibliotheken.Ich persönlich habe mir den Quellcode nicht angesehen, aber ich bin mir sicher, dass die Leute dort Ihnen einige gute Hinweise geben können.

Answer 3

Ich habe meine Erweiterungsmethoden in meine Core-Bibliotheken in der Utils-Klasse eingebunden, weil Leute, die mit meinem Framework arbeiten, die Methoden wahrscheinlich nützlich finden werden, aber für eine Massenbereitstellung, bei der der Endentwickler möglicherweise eine Auswahl an Erweiterungsmethodenbibliotheken hat, Ich würde empfehlen, alle Ihre Erweiterungen in ihren eigenen Namensraum zu legen, sogar in ihre eigene Projektdatei, damit die Leute wählen können, ob sie eine Referenz oder eine using-Anweisung oder einfach dort, wo es erforderlich ist, hinzufügen möchten, etwa so:

Core.Extensions.Base64Encode(str);

Mein Utils-Kurs ist mein bester Freund auf der ganzen Welt. Er fand statt, bevor Erweiterungsmethoden aufkamen, und sie haben nur dazu beigetragen, unsere Beziehung zu stärken.Die wichtigste Regel, die ich befolgen würde, besteht darin, den Leuten nach Möglichkeit die Wahl zu lassen, welches Erweiterungsframework sie verwenden.

Answer 4

Die Objective-C-Sprache verfügt seit Anfang der 1990er Jahre über „Kategorien“.Dies ist im Wesentlichen dasselbe wie .NET-Erweiterungsmethoden.Wenn Sie nach Best Practices suchen, möchten Sie vielleicht sehen, welche Faustregeln Objective-C-Entwickler (Cocoa und NeXT) dafür entwickelt haben.

Brent Simmons (der Autor des NetNewsWire RSS-Readers für Mac OS X und iPhone) hat heute gerade etwas über ihn gepostet neue Stilregeln für die Verwendung von Kategorien und es gab ein bisschen Diskussion in der Kakao-Community rund um diesen Beitrag.

Answer 5

Ich denke, dass es davon abhängt, welchem ​​Zweck die Erweiterungsmethoden dienen.

• Erweiterungsmethoden, die sich auf spezifische Geschäftsanforderungen eines Projekts beziehen (unabhängig davon, ob sie mit grundlegenden Datentypen oder benutzerdefinierten Objekten verbunden sind), sollten nicht in einer Bibliothek enthalten sein, die über mehrere Projekte verteilt würde.
• Erweiterungsmethoden, die sich auf grundlegende Datentypen (int, string usw.) oder generische Methoden mit einer breiteren Anwendung beziehen, könnten paketiert und über Projekte verteilt werden.

Achten Sie darauf, Erweiterungsmethoden, die kaum Anwendung finden, nicht global einzubeziehen, da sie nur Intellisense verstopfen und zu Verwirrung und/oder Missbrauch führen können.

Answer 6

Als ich zum ersten Mal von Erweiterungen erfuhr, habe ich sie wirklich überbeansprucht und missbraucht.

Aus verschiedenen Gründen bin ich größtenteils davon abgerückt, Erweiterungsmethoden zu verwenden.

Einige der Gründe, warum ich sie nicht mehr verwende, sind in Scotts Blog-Link oben aufgeführt, z. B. „Denken Sie zweimal darüber nach, bevor Sie Typen erweitern, die Sie nicht besitzen“.Wenn Sie keine Kontrolle über die Quelle der Typen haben, die Sie erweitern, kann es in Zukunft zu Problemen/Kollisionen kommen, wenn der Quelltyp einige Ergänzungen/Änderungen aufweist, z. B. wenn Sie Ihr Projekt auf eine neuere .NET-Version verschieben.Wenn die neuere .NET-Version eine Methode für den Typ mit demselben Namen wie Ihre Erweiterung enthält, wird jemand überlastet.

Der Hauptgrund, warum ich aufgehört habe, Erweiterungsmethoden zu verwenden, ist, dass man beim Lesen des Codes nicht schnell erkennen kann, wo sich die Quelle der Methode befindet und wem sie „gehört“.

Beim Durchlesen des Codes können Sie nicht erkennen, ob es sich bei der Methode um eine Erweiterung oder nur um eine Standard-NET-API-Methode für den Typ handelt.

Das Intellisense-Menü kann sehr schnell sehr chaotisch werden.