myCSharp.de - DIE C# und .NET Community
Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 
 | Suche | FAQ

» Hauptmenü
myCSharp.de
» Startseite
» Forum
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Suche
» Regeln
» Wie poste ich richtig?
» Forum-FAQ

Mitglieder
» Liste / Suche
» Wer ist wo online?

Ressourcen
» openbook: Visual C#
» openbook: OO
» Microsoft Docs

Team
» Kontakt
» Übersicht
» Wir über uns

» myCSharp.de Diskussionsforum
Du befindest Dich hier: Community-Index » Diskussionsforum » Knowledge Base » Artikel » [Einführung] Extension Methods in C# 3.0
Letzter Beitrag | Erster ungelesener Beitrag Druckvorschau | Thema zu Favoriten hinzufügen

Antwort erstellen
Zum Ende der Seite springen  

[Einführung] Extension Methods in C# 3.0

 
Autor
Beitrag « Vorheriges Thema | Nächstes Thema »
Khalid Khalid ist männlich
myCSharp.de-Poweruser/ Experte

avatar-2534.gif


Dabei seit: 19.07.2005
Beiträge: 3.501
Entwicklungsumgebung: Visual Studio 15/17
Herkunft: Hannover


Khalid ist offline

[Einführung] Extension Methods in C# 3.0

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Mit C#3.0 finden viele Neuerungen Einzug in das .Net Framework. Neben LINQ, welches wirklich genial ist, gibt es auch ein neues nettes Feature, welches erlaubt bestehende Typen mit eigenen Methoden zu erweitern: Die Extension Methods.

Nehmen wir mal an, in einem Projekt wird immer wieder auf gültige E-Mail Adressen geprüft. Die bis jetzt wohl meist angewendete Methode wird wohl sein, eine statische Klasse zu erstellen, in dem einige Helper-Methoden implementiert sind. So eine Klasse könnte folgendermaßen aussehen

C#-Code:
namespace Orcas.Extensions
{
  public static class HelperClass
  {
    public static bool IsValidEMailAddress(string email)
    {
      return true; // Logik einbinden
    }
  }
}

Die Methode in der Klasse IsValidEMailAddress könnte nun wie folgt benutzt werden.

C#-Code:
private void button1_Click(object sender, EventArgs e)
{
  string email = "BliBlaBlubb";
  if (Orcas.Extensions.HelperClass.IsValidEMailAddress(email))
    Console.Write("Ist OK!");
}

Viel interessanter wäre es doch, wenn der Type string diese Funktion bereits bereitstellen würde. Dann könnte man im Code einfach folgendes schreiben

C#-Code:
private void button1_Click(object sender, EventArgs e)
{
  string email = "BliBlaBlubb";
  if (email.IsValidEMailAddress())
    Console.WriteLine("Ist OK!");
}

Mit den neuen Extension Methods in C#3.0 ist das jetzt endlich möglich. Die Änderung, die gemacht werden muss, um das zu erreichen sind minimal. Die HelperClass muss nur an einer Stelle angepasst werden, damit das oben gezeigte Beispiel funktioniert.

C#-Code:
namespace Orcas.Extensions
{
  public static class HelperClass
  {
    public static bool IsValidEMailAddress(this string email)
    {
      return true; // Logik einbinden
    }
  }
}

Der Unterschied zur oberen Deklaration unterscheidet sich nur in den Schlüsselwort this in der Methodendeklaration. Wird in der Deklaration this verwendet vor dem ersten Parameter, wird dem Compiler mitgeteilt, das es sich hierbei um eine Extension für den Type string handelt.
Der Namespace Orcas.Extensions muss eingebunden werden, damit IntelliSense die Extension erkennt. Diese bietet er dann auch sofort in seiner Auswahlliste mit an. Die Extension Methode kann natürlich dann auch mit allen anderen Methoden des Typs verbunden werden.
In den bisher gezeigten Beispiel könnte es dann zum Beispiel auch so aussehen

C#-Code:
private void button1_Click(object sender, EventArgs e)
{
  string email = "BliBlaBlubb";
  if (email.Trim().ToLower().IsValidEMailAddress())
    Console.WriteLine("Ist OK!");
}

Wie man sieht, spart man sich durch Extensions einige Zeilen Code. Leider haben Extensions nicht nur Vorteile, sondern auch einige Nachteile.
Extensions haben die niedrigste Priorität beim Compilieren. Nehmen wir an, das eine selbtgeschriebene Klasse die Methode IsValid implementiert hat, die public ist. Wird jetzt eine Extension für die Klasse geschrieben, die den Namen IsValid hat, wird diese von IntelliSense nicht angeboten und auch der Compiler wird diese ignorieren. Das heißt, das man immer die definiton des Basistyps im Auge halten sollte.

Zudem ist es umständlich Extensions zu debuggen. In der aktuellen Beta 1 von Orcas hat bei mir der Compiler immer mal wieder versagt in den Aufruf der Extension zu springen. Ich denke aber mal, das das mit den neueren Versionen behoben sein wird. Aussagen von MS dazu, habe ich nicht gefunden.

Bis dahin
Khalid
21.05.2007 07:46 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
sheitman sheitman ist männlich
myCSharp.de-Mitglied

Dabei seit: 02.11.2005
Beiträge: 1.047


sheitman ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Glaub da werden sich so einige freuen. smile
21.05.2007 09:47 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
svenson svenson ist männlich
myCSharp.de-Mitglied

Dabei seit: 15.04.2005
Beiträge: 8.746
Entwicklungsumgebung: Visual Studio .NET 2003
Herkunft: Berlin


svenson ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Aus Qualitätssicht kommt das gleich nach Goto. Von Kapselung keine Spur. Kommt nicht in meinen Code....
21.05.2007 10:18 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
herbivore
myCSharp.de-Poweruser/ Experte

avatar-2627.gif


Dabei seit: 11.01.2005
Beiträge: 49.461
Entwicklungsumgebung: csc/nmake (nothing is faster)
Herkunft: Berlin


herbivore ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Hallo svenson,

soweit ich das beurteilen kann, wird die Kapselung durch Extension Methods überhaupt nicht verletzt. Eine Extension Method kann nur auf die öffentlichen Member der zu erweiternden Klasse zugreifen, oder? Es geht also nur um etwas syntaktischen Zucker beim Aufruf der Methoden: email.IsValidEMailAddress() statt HelperClass.IsValidEMailAddress(email).

herbivore
21.05.2007 10:46 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Khalid Khalid ist männlich
myCSharp.de-Poweruser/ Experte

avatar-2534.gif


Dabei seit: 19.07.2005
Beiträge: 3.501
Entwicklungsumgebung: Visual Studio 15/17
Herkunft: Hannover

Themenstarter Thema begonnen von Khalid

Khalid ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Richtig, eine Extension Method kann nur auf die öffentlichen Member/Methoden eines Typs zugreifen. Die Kapslung wird in keiner weise verletzt. Es ist, wie herbivore schon sagt, einfach nur ein "syntaktischer Zucker".

BTW: LINQ basiert vollkommen auf Extension Methods. Ich denke mal, wenn das die Kapselung verletzen würde, würde MS das nicht so benutzen.
21.05.2007 11:38 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Peter Bucher Peter Bucher ist männlich
myCSharp.de-Poweruser/ Experte

avatar-4103.jpg


Dabei seit: 17.03.2005
Beiträge: 5.880
Entwicklungsumgebung: VS 2017 / VS Code
Herkunft: Zentralschweiz


Peter Bucher ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Hallo Khalid

Danke für diese Darstellung.
Das sieht doch richtig cool aus :-)


Gruss Peter

Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Peter Bucher am 21.05.2007 11:42.

21.05.2007 11:42 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
svenson svenson ist männlich
myCSharp.de-Mitglied

Dabei seit: 15.04.2005
Beiträge: 8.746
Entwicklungsumgebung: Visual Studio .NET 2003
Herkunft: Berlin


svenson ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Zitat:
Original von herbivore
soweit ich das beurteilen kann, wird die Kapselung durch Extension Methods überhaupt nicht verletzt.

Das kommt darauf an, was man unter Kapselung versteht. Tendenziell bieten Extension Methods die Möglichkeit die Applikationslogik wild in verschiedenen Fremdklassen zu verstecken. Erhöht nicht gerade die Wartbarkeit.

Dann wäre da noch die unsichtbare Kopplung. Klasse A erweitert Klasse B. Die Erweiterung von B wird genutzt von C. Obwohl A nicht von C genutzt wird, entsteht eine Koppelung über B. Wir A aus dem Code entfernt wird, läuft C nicht mehr.

Was passiert eigentlich, wenn zwei Assemblies gleichlautende Erweiterungen vornehmen aber dann dynamisch zusammen in eine AppDomain geladen werden? Gibt es dann zwei String-Klassen? Gewinnt einer?
21.05.2007 11:51 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Peter Bucher Peter Bucher ist männlich
myCSharp.de-Poweruser/ Experte

avatar-4103.jpg


Dabei seit: 17.03.2005
Beiträge: 5.880
Entwicklungsumgebung: VS 2017 / VS Code
Herkunft: Zentralschweiz


Peter Bucher ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Hallo svenson

Ich denke darüber könnte man tagelang streiten.
Es ist doch aber so, wenn man konsequent vorgeht, hat man eine einzige Helper Klasse, die dann überall genutzt wird.
Evt. sogar Global für alle Projekte, was IMO wirklich Sinn machen würde.

So gesehen, ergeben sich "keine" Probleme.
Höchstens, wenn diese Helperklassen dann in einer Komponente mitgeliefert werden, oä.. Da könnte es tatsächlich krachen.

Aber dort sollte man halt Abstand von diesen Methoden nehmen~
Oder aber Präfixe für die Methoden verwenden... dann kann man dieser "syntactic sugar" aber gleich weglassen (Bei den Komponenten) ;-)


Gruss Peter

Dieser Beitrag wurde 2 mal editiert, zum letzten Mal von Peter Bucher am 21.05.2007 14:12.

21.05.2007 12:00 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
herbivore
myCSharp.de-Poweruser/ Experte

avatar-2627.gif


Dabei seit: 11.01.2005
Beiträge: 49.461
Entwicklungsumgebung: csc/nmake (nothing is faster)
Herkunft: Berlin


herbivore ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Hallo svenson,

Zitat:
Das kommt darauf an, was man unter Kapselung versteht. Tendenziell bieten Extension Methods die Möglichkeit die Applikationslogik wild in verschiedenen Fremdklassen zu verstecken. Erhöht nicht gerade die Wartbarkeit.

das stimmt einerseits und andererseits nicht. Denn wenn die zu erweiternde Klasse die benötigte Funktionalität nicht bietet, muss diese so oder so in eine zusätzliche (Helper-)Klasse. Durch Extension Methods wird jetzt aber wenigstens der sonst nur implizite Zusammenhang zwischen Helperklasse und eigentlicher Klasse explizit ausgedrückt. Es wird also was die Kapselung angeht also eher besser denn schlechter.

Zitat:
Dann wäre da noch die unsichtbare Kopplung. Klasse A erweitert Klasse B. Die Erweiterung von B wird genutzt von C. Obwohl A nicht von C genutzt wird, entsteht eine Koppelung über B. Wir A aus dem Code entfernt wird, läuft C nicht mehr.

Das stimmt nicht. Denn da der erste Parameter der Extension Method zwangsläufig vom Typ A ist, besteht die Koppelung zwischen A und C nicht nur implizit, sondern auch explizit.

Zitat:
Was passiert eigentlich, wenn zwei Assemblies gleichlautende Erweiterungen vornehmen aber dann dynamisch zusammen in eine AppDomain geladen werden? Gibt es dann zwei String-Klassen? Gewinnt einer?

Da AppDomains weitgehend gegeneinander entkoppelt sind, spielt es in der einen AppDomain keine Rolle, ob es in der anderen AppDomain genauso oder anders ist.

Du hast natürlich recht, dass man mit Extension Methods auch Schindluder treiben kann, aber mir scheint, dass deine Vorbehalte übertrieben sind.

herbivore
21.05.2007 12:05 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
svenson svenson ist männlich
myCSharp.de-Mitglied

Dabei seit: 15.04.2005
Beiträge: 8.746
Entwicklungsumgebung: Visual Studio .NET 2003
Herkunft: Berlin


svenson ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Zitat:
Original von herbivore
das stimmt einerseits und andererseits nicht.

Wenn man sauber arbeitet und alle Extensions in wirklichen Helper-Klassen unterbringt, dann ist es im Prinzip kein Unterschied. Aber da die Notwendigkeit von Helperklassen entfällt wird Faulheit obsiegen... smile

Zitat:
Das stimmt nicht. Denn da der erste Parameter der Extension Method zwangsläufig vom Typ A ist, besteht die Koppelung zwischen A und C nicht nur implizit, sondern auch explizit.

Der erste Parameter ist vom Typ B, oder? IsValidEmail() bekommt ja auch nur (this) string als Parameter.

Zitat:
Da AppDomains weitgehend gegeneinander entkoppelt sind, spielt es in der einen AppDomain keine Rolle, ob es in der anderen AppDomain genauso oder anders ist.

Es geht doch gerade darum, dass zwei statisch compilierte Module (Assemblies) in ein dynamisches Umfeld geladen werden. Da bisher auch alle Typen statisch waren, gab es bestenfalls Versionskonflikte. Jetzt scheint mir das Szenario weitaus komplexer. Im Prinzip müßte jede Klassen eine Kopie derjenigen Klassen erhalten, die sie erweitert. Aber wie schaut es dann noch mit Typidentität aus? Welche Auswirkungen hat das auf Reflection?

Eigentlich kann es wirklich nur so sein wie du sagtest: In Wirklichkeit wird nur eine Helperklasse erzeugt und der Compiler besorgt den Rest.

Damit wäre auch das obige Problem aus der Welt. Verschärft aber leider das Wartbarkeitsproblem. Man könnte wirklich zwei Methoden gleichen Namens haben, die eine Klasse erweitern. Je nach Assembly-Zugehörigkeit wird die jeweilige Implementierung aufgerufen. Da wäre es doch schön, wenn Extensions auf internal-Sichtbarkeit beschränkt blieben.

Damit wären Extension Methods wirklich rein syntaktischer Zucker und somit Reflection nicht zugänglich (zumindest nicht in der erweiterten Klasse). D.h. es werden keine Klassen erweitern, sondern man kann Code so schreiben als WÄREN sie erweitert. Und das ganze funktioniert nur mit statischer Bindung.

*EDIT*

Ist tatsächlich so. Es gibt keine Erweiterung von Klassen zur Laufzeit in .NET. Extensions Methods sind reine Abkürzungsschreibweisen von Aufrufen über statische, automatisch generierte Helperklassen. Ob das aus Sicht der Codewartbarkeit ein Gewinn darstellt wird sich zeigen. Zumindest wird es der Lesbarkeit zuträglich sein....

Dieser Beitrag wurde 3 mal editiert, zum letzten Mal von svenson am 21.05.2007 12:33.

21.05.2007 12:22 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
herbivore
myCSharp.de-Poweruser/ Experte

avatar-2627.gif


Dabei seit: 11.01.2005
Beiträge: 49.461
Entwicklungsumgebung: csc/nmake (nothing is faster)
Herkunft: Berlin


herbivore ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Hallo svenson,

Zitat:
Der erste Parameter ist vom Typ B, oder?

du hast Recht. Ich hatte das falsch herum gelesen. Also das B die Klasse ist, die A erweitert.

Da A aber die Klasse mit der Extension Method ist, hast du natürlich recht. Der Typ A taucht in C nicht auf. Allerdings besteht der Bezug immer noch über die Methode (weshalb der Code ja auch nicht mehr läuft bzw. sich erst gar nicht übersetzen lassen wird, wenn man A (und damit die Extension Methode) entfernt. Deshalb sehe ich trotzdem kein Problem.

herbivore
21.05.2007 12:36 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
talla talla ist männlich
myCSharp.de-Poweruser/ Experte

avatar-3214.jpg


Dabei seit: 20.07.2003
Beiträge: 6.862
Entwicklungsumgebung: VS 2010
Herkunft: Esslingen


talla ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Zitat:
Original von svenson

Zitat:
Das stimmt nicht. Denn da der erste Parameter der Extension Method zwangsläufig vom Typ A ist, besteht die Koppelung zwischen A und C nicht nur implizit, sondern auch explizit.

Der erste Parameter ist vom Typ B, oder? IsValidEmail() bekommt ja auch nur (this) string als Parameter.

Ja, er ist vom Typ B um bei deinem Beispiel zu bleiben. Trotzdem ist die Kopplung explizit, da du explizit den Typen einbinden musst(meist einfach per using den entsprechenden Namespace) in dem die Extension Method definiert wird, weil...

Zitat:
Obwohl A nicht von C genutzt wird, entsteht eine Koppelung über B.

Nein, durch die Benutzung der Extension Method wird A von C genutzt! Nehmen wir mal an wir hätten eine Extension Method für String die sich WhitespaceToUnderscore nennt:

C#-Code:
namespace ExtensionMethods {
    public static class Extensions {
        public static string WhiteSpaceToUnderscore(this string param) {
            return param.Replace(' ', '_');
        }
    }
}

Und wir haben irgendwo nen Hauptprogramm

C#-Code:
using ExtensionMethods;

namespace ConsoleApplication1 {
    class Program {
        static void Main(string[] args) {
            Console.WriteLine("Hallo Welt!".WhiteSpaceToUnderscore());
            Console.ReadLine();
        }
    }
}

Nie gefragt wieso die Klasse und die Extension Method statisch sein müssen?
Der Compiler macht einfach das draus:

C#-Code:
Console.WriteLine(Extensions.WhiteSpaceToUnderscore("Hallo Welt!"));

mehr steckt da nicht hinter, keine generierten Helperklassen etc. Nur nen bissle syntaktischer Zucker.

In dieser, ich sag mal expliziten Schreibweise, erübrigt sich auch das Problem mit der Mehrdeutigkeit wenn zwei gleichlautende Extension Methods dynamisch geladen werden aus verschiedenen Typen, hier in dem Fall ist der nämlich mit angegeben. Aber dynamisch fällt mir grad auch gar net ein wie ich ne Extension Method invoken könnte auf einen bestimmten Typ, da fällt mir auch nur diese explizite Variante ein. Glaube da sind Extension Methods echt harmloser als es den anschein hat.
21.05.2007 12:46 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Golo Roden Golo Roden ist männlich
myCSharp.de-Mitglied

avatar-2167.png


Dabei seit: 04.10.2003
Beiträge: 4.207
Entwicklungsumgebung: Visual Studio 2010
Herkunft: Riegel am Kaiserstuhl


Golo Roden ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Auf der PDC 2005, wo C# 3.0 vorgestellt wurde, hieß es von MS sinngemäß:

Extension Methods mussten in C# 3.0 wegen Linq rein, der Anwender soll nach Möglichkeit aber die Finger davon lassen, weil das Gefahrenpotenzial, Mist damit zu machen, viel zu groß ist.

Die Aussage kam IIRC von Anders Heijlsberg.
21.05.2007 12:50 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
svenson svenson ist männlich
myCSharp.de-Mitglied

Dabei seit: 15.04.2005
Beiträge: 8.746
Entwicklungsumgebung: Visual Studio .NET 2003
Herkunft: Berlin


svenson ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Zitat:
Original von talla
Nie gefragt wieso die Klasse und die Extension Method statisch sein müssen?

Ach, dass auch die Klasse statisch sein muss, war mir entgangen. Das entkräftet zumindest die meisten der Kritikpunkte. Die unsichtbaren Kopplungen bleiben allerdings. Aber da Extensions ja im IL-Code ausgezeichnet werden, kann ein Visualisierungstool diese Beziehungen ja wenigstens sichtbar machen.

Ist in Extension Methods eigentlich der Zugriff auf private Member der zu erweiternden Klasse erlaubt? Dürfte ja eigentlich nicht der Fall sein.

Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von svenson am 21.05.2007 13:07.

21.05.2007 13:01 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Khalid Khalid ist männlich
myCSharp.de-Poweruser/ Experte

avatar-2534.gif


Dabei seit: 19.07.2005
Beiträge: 3.501
Entwicklungsumgebung: Visual Studio 15/17
Herkunft: Hannover

Themenstarter Thema begonnen von Khalid

Khalid ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Sorry, hätte ich im Artikel vielleicht erwähnen sollen, das die Extensions nur in statischen Klassen erlaubt sind.

Zugriff auf private Member der zu erweiternden Klasse ist nicht möglich, weil dann könnte man damit wirklich bockmist machen.
21.05.2007 13:45 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Robert G Robert G ist männlich
myCSharp.de-Mitglied

avatar-1907.png


Dabei seit: 12.04.2006
Beiträge: 347
Entwicklungsumgebung: VS05 (Chrome/C#);TurboDel phi
Herkunft: München


Robert G ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Zitat:
Original von svenson
Ach, dass auch die Klasse statisch sein muss, war mir entgangen. Das entkräftet zumindest die meisten der Kritikpunkte. Die unsichtbaren Kopplungen bleiben allerdings. Aber da Extensions ja im IL-Code ausgezeichnet werden, kann ein Visualisierungstool diese Beziehungen ja wenigstens sichtbar machen.

Ex-Methods sind nix weiter als statische Methoden, die mit dem ExtensionAttribute markiert werden, die Klasse selbst muss ebenfalls statisch sein und auch mit dem gleichen Attribut markiert sein.

Das ganze existiert auch nur in deinem Source, nicht im IL code.
Dem Compiler wird durch die Attribute nur gezeigt, dass er diese komische Methode, die er gar nicht in der Klasse finden kann, in einer andere Klasse suchen könnte.
Der Namespace der Extension class muss übrigens ebenfalls als using-clause benutzt werden.

Zitat:
Ist in Extension Methods eigentlich der Zugriff auf private Member der zu erweiternden Klasse erlaubt? Dürfte ja eigentlich nicht der Fall sein.

Wie gesagt: keine Zauberei, nur statische Methoden.


Und wirklich Sinn macht das eigentlich nur bei generischen Methoden.
Nehmen wir mal einen abtrakten Bleistift:

C#-Code:
[Extension]
public static class Miep
{
  [Extension]
  public static IEnumerable<T> GetItemsGreaterThan<T>(IEnumerable<T> items, IComparable<T> minValue)
  {
     foreach(T item in items)
       if(minValue.CompareTo(item) < 0)
         yield return item;
  }
}

Das ganze ließe sich jetzt so aufrufen:

C#-Code:
int[] someInts = {1, 2, 3, 4, 5, 6};
foreach(int found in Miep.GetItemsGreaterThan<int>(someInts , 3))
  Console.WriteLine(found);

IMHO hübscher wäre es so:

C#-Code:
int[] someInts = {1, 2, 3, 4, 5, 6};
foreach(int found in someInts.GetItemsGreaterThan(3))
  Console.WriteLine(found);

Wenn man es sinnvoll verwendet, lassen sich auf die Art etwas zu wortreiche Zeilen schön vereinfachen. (Für den Leser)


LINQ selbst benutzt Ex-Methods nur indirekt, da wir es dort mit syntaktischen Tricks zu tun haben, die wieder über syntaktische Tricks gestülpt werden.
Wenn deine Klasse/Interface zum Beispiel kein OrderBy enthält, aber irgendeine Extension class eine passende Methode zur Verfügung stellt, dann wird dieses OrderBy benutzt.
Praktisch eine Art Duck-typing für statische Methoden. verwundert

btw: Was wirklich interessant an Ex-Methods ist, ist die Frage ob MS sie weit genug abgespeckt hat, um die Patente von CodeGEAR/Borland zu Class helpers nicht zu verletzen. großes Grinsen

Dieser Beitrag wurde 2 mal editiert, zum letzten Mal von Robert G am 21.05.2007 16:50.

21.05.2007 16:48 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
Zwischen diesen beiden Beiträgen liegt mehr als ein Monat.
0815Coder
myCSharp.de-Mitglied

avatar-242.gif


Dabei seit: 08.12.2005
Beiträge: 767


0815Coder ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

Was an ExtensionMethods aucuh wirklich interessant ist, ist folgendes:

C#-Code:
interface IBla
{
  string DoSomething(int value, bool yesAll);
}

public static IBlaExtension
{
  public static void DoSomething(this IBla blubb, int value)
  {
    return blubb.DoSomething(value, true);
  }
}

schon hat man ein kleines interface, das aber dennoch einen zweiten overload unterstützt, und das beste: den overload muss nicht jede klasse implementieren, die vom interface ableitet.

(übrigens funktioniert das bei mir auch ohne das ExtensionAttribute).
02.07.2007 23:04 E-Mail | Beiträge des Benutzers | zu Buddylist hinzufügen
ikaros
myCSharp.de-Mitglied

Dabei seit: 27.05.2005
Beiträge: 1.739


ikaros ist offline

Beitrag: beantworten | zitieren | editieren | melden/löschen       | Top

@Khalid: Lies mal erst die MS-Doku durch.
Extensions sind Ausnahmen, die man begründen muss. Sie sind Spezialfällen vorbehalten.
Das Verbreiten dieser Mechanismen ist eher kontraproduktiv zu sehen, da exzessive Anwendung einfach nur der kürzeste Weg zur Müllhalde ist.
Ähnliche Mechanismen gab es schon seit 1.0(vor allem im Bereich Controls), das vwurde jetzt beträchtlich Erweitert. Ich sehe das eher als Gefahr für wiederverwendbaren Code, wenn es ohne zu Hinterfragen für jeden Kram missbraucht wird.
Eigentlich steckt ja nur ein simpler Dekorateur dahinter, man muss ihn aber als solchen Begreifen und Anwenden.
Was ich deiner Ausführung bemängele:
-Unreflektive Featuritis
-das Hinstellen als jederzeit gebrauchsfähige Lösung
-kein Hinweis auf Gefahren, Sinn oder Unsinn

Naja, ich kann jetzt nur noch auf die recht schwache technische Hürde hoffen, das jetzt keine Sintflut kommt...
02.07.2007 23:53 Beiträge des Benutzers | zu Buddylist hinzufügen
Baumstruktur | Brettstruktur       | Top 
myCSharp.de | Forum Der Startbeitrag ist älter als 12 Jahre.
Der letzte Beitrag ist älter als 12 Jahre.
Antwort erstellen


© Copyright 2003-2019 myCSharp.de-Team | Impressum | Datenschutz | Alle Rechte vorbehalten. | Dieses Portal verwendet zum korrekten Betrieb Cookies. 15.09.2019 19:59