Bevor Sie anfangen, mich auf Duplikate zu verweisen, wissen Sie, dass ich fast alle Beiträge zu SO über Erweiterungsmethoden gelesen habe. Ich versuche nur, den Advokaten des Teufels für eine Minute zu spielen, um die Alternative zu meiner Arbeitsmeinung in Erwägung zu ziehen.
In letzter Zeit arbeitete ich an einem Projekt und es entstand ein Bedürfnis nach einer Methode, um eine Schnittstelle zu bilden. Also schlug ich vor, eine Erweiterungsmethode zu schreiben und sie wurde abgeschossen. Zu sagen, dass es komplexer und schwieriger zu debuggen ist.
Ich habe natürlich argumentiert und bin auf SO gestoßen, um all die wundervollen Beiträge zu finden, die die vielen Gründe zeigen, warum man Erweiterungsmethoden verwendet. Nicht zu vergessen, dass viele .NET-Frameworks sie verwenden. Wir haben es schließlich nicht benutzt, da ich vom Team überstimmt wurde.
Aber dann hat es mich zum Nachdenken gebracht, gibt es Zeiten, in denen eine Erweiterungsmethode verwendet werden könnte, aber nicht sollte?
Ich konnte mir wirklich keine Gedanken machen, dachte aber, ich würde hier posten und sehen, ob irgendjemand andere Gründe hätte, warum sie nicht benutzt werden sollten.
Jedes Mal, wenn Sie eine Funktion haben, die "allgemein anwendbar" für ein Objekt eines bestimmten Typs ist, unabhängig vom Status, ist eine Erweiterungsmethode eine gute Wahl.
Heute habe ich beispielsweise unserer Codebasis zwei neue Erweiterungsmethoden hinzugefügt:
%Vor%Beide sind im Allgemeinen gültig für die Typen, die sie erweitern, unabhängig vom Zustand der Instanz oder wo wir sie verwenden.
Wenn Ihre Methode diese Kriterien nicht erfüllt, sollte sie wahrscheinlich in eine Hilfsmethode verschoben werden, die näher am Kontext liegt, in dem der jeweilige Fall immer wahr ist oder einfach überprüft werden kann.
Zum Beispiel hat ein Entwickler kürzlich dies als eine Erweiterungsmethode nominiert:
%Vor%Hier gibt es zwei Probleme: Erstens wird dies auf allen Strings in der Anwendung erscheinen, obwohl die Anzahl der Strings, die jemals für diesen Fall in Frage kommen, sehr klein ist. Also haben wir die erste Regel gebrochen, da sie unabhängig vom Status nicht nützlich ist. In ähnlicher Weise, aber zweitens ist der Verbraucher dieser Funktionalität auf einen einzelnen Parser für einen bestimmten Konnektor für ein externes System beschränkt. Die Implementierung implementierungsspezifischer Funktionen in den Namespace für allgemeine Verwendung ist daher nicht sinnvoll. Dies wurde zu einer Hilfsmethode im Parser heruntergestuft.
Was die Lesbarkeit und das Debugging betrifft, ist das für einen Entwickler mit einem vernünftigen Kenntnisstand einfach nicht richtig.
Im Allgemeinen, wenn Sie den Quellcode für die Assembly kontrollieren und das Hinzufügen der Methode keine Änderungen an existierendem Code bewirkt (was der Fall wäre, wenn zB LINQ nicht über Erweiterungsmethoden implementiert wurde), ist es besser um einfach eine normale Methode hinzuzufügen.
Diese Diskussion von Der Abschnitt Framework Design Guildelines zu Erweiterungsmethoden enthält einige gute Ratschläge. Ich denke, der relevante Teil für Ihr Szenario ist:
Bereitstellung von Hilfsfunktionen, die für jede Implementierung einer Schnittstelle relevant sind, wenn diese Funktionalität in Bezug auf die Kernschnittstelle geschrieben werden kann.
Wenn Ihre vorgeschlagene Verwendung diesen Test nicht bestanden hat, sollte sie abgeschossen worden sein.
Ich würde sagen, Sie sollten sie vermeiden, wenn sie "die Absicht des Codes nicht klarer machen". Natürlich, ob ein Code (oder Coding-Stil) "klarer" ist oder nicht, variiert stark zwischen den Menschen, so dass es ziemlich nutzlos ist. (Ich hatte einen Chef, der sagte, wir sollten Interfaces vermeiden, weil sie den Code "zu komplex und schwer zu verstehen" gemacht haben)
Erweiterungsmethoden ermöglichen das Hinzufügen von Methoden zu vorhandenen Typen, ohne einen neuen abgeleiteten Typ zu erstellen, den ursprünglichen Typ neu zu kompilieren oder anderweitig zu ändern.
Jedes Mal, wenn Sie die Absicht und das Design für das Feature brechen, würde ich empfehlen, die Verwendung einer Erweiterungsmethode zu überdenken. Ich sehe ein paar Situationen, wenn Sie keine Erweiterungsmethode verwenden möchten:
1) Ändern des Objektmodells für eine Erweiterungsmethode: Die Klasse, für die Sie eine Erweiterung erstellen möchten, ist eine abstrakte Klasse. Dies erfordert entweder, dass Sie jeder geerbten Klasse ihre eigene Version der Erweiterung geben oder abstract von der Klasse entfernen. In beiden Fällen ändern Sie das Objektmodell, um eine Erweiterungsmethode zu verwenden.
2) Das Dekorationsmuster wird vergessen: Die Anzahl der Erweiterungsmethoden, die Sie für einen erstellen Klasse überschreitet drei. Ich finde es einfacher, das Domänen- / Objektmodell mit dekorierten Objekten zu organisieren, zu kommunizieren und zu pflegen als mit erweiterten Objekten. Das Gegenteil trifft jedoch auch zu: Wenn ein dekoriertes Objekt weniger als vier Methoden hat, finde ich in meinem Projekt viele fast "leere" Objekte.
3) Private Funktionen : Private Funktionen sind zum Ändern (Erstellen, Löschen usw.) gedacht. Die Objekt- und Erweiterungsmethoden sollen den Typ verwenden, ähnlich wie eine Struktur. Wenn Sie feststellen, dass die Erweiterung einer anderen Instanz des Typs zugewiesen ist, sollte sie wahrscheinlich nicht in einer Erweiterung enthalten sein.
Tags und Links c# design extension-methods