Jongens van Wazzup

Een ieder die werkt met het .Net Framework 3.0 of hoger werkt vast en zeker met de zogenaamde Extension Methods. Althans, dat dacht ik. Toch spreek ik regelmatig vakgenoten die er weinig of geen gebruik van maken. Hoe komt dit toch? Is het het aloude onbekend maakt onbemind of licht er meer aan ten grondslag?

Maar eerst, wat is een Extension Method? Vrij vertaald is het een uitbreidingsfunctie. Een functie die wordt toegevoegd aan de bestaande set van functies van een bepaald Type. Deze functie is statisch en kan te allen tijd worden aangeroepen. Een klein voorbeeld: het object van het Type String beschikt niet van nature over de mogelijkheid om te bepalen of de tekst die het bevat een geldig e-mailadres bevat. De volgende syntax zou tot niets leiden:

var s = "misschien een emailadres";
if (s.IsValidEmail()) continue;

Zodra ik echter de Extension Method IsValidEmail heb gedefinieerd, dan kan ik deze te pas en te onpas aanroepen. Nu hoor ik de lezer al denken: "leuk allemaal, maar we hadden toch al de gewone 'helper' methods die ik in mijn bibliotheek had staan?" Inderdaad, die heb je al, en ik pleit er voor om deze af te stoffen en desnoods zelfs te herschrijven naar Extension Methods. Waarom? Omdat het zo veel meer leesbare code oplevert!

Nu hoorde ik laatst een collega van mij opperen dat er ook nadelen zitten aan het gebruik van Extension Methods. De nadelen die ik later vond stonden gewoon vermeld in de msdn documentatie. En ja, deze zou je als nadelen kunnen betitelen, zelf zie ik ze als slechts een kleine beperking op het grote gemak dat deze functies ons bieden. Volgens de msdn documentatie is het beter om je eigen types te definiëren daar waar mogelijk, je loopt immers het risico dat het Type dat je uitbreidt door een andere partij wordt gewijzigd. Daarmee komt je Extension Method potentieel in de gevarenzone.

Deze waarschuwing uit de documentatie moeten we wel in de gaten houden, het is een terecht punt. Niettemin, denk aan de kracht die Visual Studio je nu kan bieden! Al die oude 'helper' methods worden nu via IntelliSense aangeboden (mits je uiteraard de namespace van de extensionmethod in je using directives hebt geplaatst). Geen uitingen meer van: 'welke functie had ik hier voor bedacht!'

Vandaag heb ik nog een Extension Method voor een simpele afvanging van is null gemaakt. Ik zat met het uitvragen van custom properties in een Xml node.

var s = node.GetProperty("SomePropertyName").Value;

Zodra de property niet gevonden zou worden, zou ik een Null-reference Exception om mijn oren krijgen. Bedenk nu dat ik vele van deze regels code moest bewerken. De volgende oplossing werkt dan wel, maar zou mijn code enorm 'vervuilen':

var s = node.GetProperty("SomePropertyName")!=null?
                node.GetProperty("SomePropertyName").Value:
                   String.Empty;

Liever maak ik snel een Extension method aldus:

public static string GetNullableValue(this Property value)
{
   if (value == null) return string.Empty;
   return value.Value;
}

Dit zorgt er voor dat ik nu elke regel als volgt kan toepassen:

var s = node.GetProperty("SomePropertyName").GetNullableValue();

Dus, waarom gebruik ik bijna overal een Extension Method:

• leesbare code;
• ondersteuning IntelliSense;
• snelle opbouw van mijn codebibliotheek;
• en het is zoooo makkelijk.