C#

Ik ga verhuizen!

Dennis Vroegop — Tue, 07 Mar 2006 00:07:00 GMT

Nou ja.. ik niet, maar mijn blog wel. En wel naar http://www.dotned.nl/blogs/dennis_blog/default.aspx

Dus vanaf nu kun je me daar vinden, mocht je geinteresseerd zijn in .net, 'from the trenches' en alle andere dingen die ik beschreef.

Hope to see you on the other side!

Dennis

Veel, heeeeel veel info over Linq

Dennis Vroegop — Thu, 16 Feb 2006 12:20:00 GMT

Als je bezig bent met Linq, is het wellicht handig om hier eens naar te kijken: http://objectsharp.com/blogs/barry/archive/2005/09/13/3395.aspx

Hier vindt je een verzameling met links naar Linq...

Visual Studio Team Foundation Server RC

Dennis Vroegop — Wed, 08 Feb 2006 14:59:00 GMT

De release candidate van TFServer is beschikbaar. Dat betekent normaal gesproken dat we erg dicht bij de uiteindelijke versie zitten, deze is gepland voor ergens in maart.

Ik had Beta3 Refresh al geinstalleerd en de upgrade ging relatief eenvoudig. Er zijn wel wat verschillen tussen B3 en RC, dus zorg ervoor dat je eerst de documentatie die er bij zit goed leest! Ik had wat issues met betrekking tot de domain controller en ook klaagde de installer over de reeds aanwezige databases. Op zich was dit niet zo'n probleem: ik had nog geen echte code in de databases zitten. Ik kon gewoon de oude data weggooien en de installer een nieuwe database laten genereren. Voor de mensen die dat niet kunnen: er zit in de download een aantal tools die je helpen met de migratie.

Er is een Go-Live licentie voor zowel Beta 3 als voor de RC beschikbaar, dus niets staat je in de weg om Foundation Server eens te proberen! Ik moet zeggen dat ik erg gecharmeerd ben van het hele product.

Ok, er is niets nieuws onder de zon. Alles wat Foundation Server je biedt was al beschikbaar in de een of andere vorm. Laten we eens kijken:

Team Pages. Tja, in Sharepoint Services kon je dat al, het voordeel nu is dat je een template hebt.
Integrated Unit Testing. nUnit, wie kent het niet?
MSBuild: nAnt is een hele goede, open source tool die hetzelfde doet
Work Item tracking: ook dit kon je al doen met Sharepoint Services

En zo zijn er nog veel dingen die je al lang kunt doen met gratis en/of open source software.

Waarom ben ik dan toch zo enthousiast over Foundation Server? Wel, de reden daarvoor is dat je nu alles in een systeem hebt. Dat systeem is nog eens gestandaardiseerd ook: bedrijven zullen veel sneller een dergelijke toolset van Microsoft gaan gebruiken dan dat ze de beheerder opdracht geven een tiental open source tools te downloaden en installeren. Ik zeg niet dat ik het met een dergelijk beleid eens ben, maar het is wel wat ik om me heen zie. Het is het idee “Als het van Microsoft is, dan is het wel goed.” Het leuke is dat ze in dit geval nog eens gelijk hebben ook.

Ik heb mijn eerste projecten nu in Foundation Server staan en de werking van de tools (met als belangrijkste Team Explorer) is erg intuitief.

Voor veel tips en tutorials verwijs ik je even door naar http://teamsystemrocks.com Deze site staat vol met links naar blogs, tuturiol video's en andere interessante zaken.

Happy coding!

Dave Sussman op de dotNED bijeenkomst

Dennis Vroegop — Mon, 30 Jan 2006 16:40:00 GMT

Eens in de zoveel tijd mogen we bij dotNED, de Nederlandse .NET gebruikersgroep een spreker van wereldfaam uitnodigen. Donderdag 26 januari was het weer zover, we hadden Dave Sussman dit keer te gast, die een verhaal vertelde over caching in ASP.Net 2.0 en SQLServer 2000 en 2005.

We hadden 75 inschrijvingen, daarvan kwamen er ongeveer 65 opdagen. Die tien die er niet waren hebben een hele interessante avond gemist! Na de reguliere sessie (voor zover je van regulier kunt spreken) werd het tijd voor Q&A. Iedereen kon vragen wat hij wilde, als het maar met ASP.Net 2.0 te maken had. Er kwamen een aantal hele goede vragen en ook antwoorden!

Voor iedereen die er niet bij was: hou http://www.dotned.nl in de gaten voor meer van dit soort avonden!

Foto: Dave Sussman aan het voorbereiden.

Microsoft Virtual Labs

Dennis Vroegop — Tue, 17 Jan 2006 14:38:00 GMT

Even een kort berichtje.

Je kent het wel: je wilt eens spelen met de laatste tools van Microsoft, maar die moet je weer helemaal downloaden, installeren, configureren en daarna weer van je machine afhalen (zo'n harde schijf is immers zo vol, niet waar?)

Wellicht is dit dan een oplossing: Microsoft heeft tegenwoordig de Virtual Labs online staan. Dat is in principe niets anders dan een batterij servers die allemaal Virtual Server draaien met daarop geconfigureerd een aantal tools en platforms. Jij kunt daar dan op inloggen en dan heb je die machine zo'n 90 minuten tot je beschikking. Er zijn meestal een aantal oefeningen bij zodat je eens kunt spelen met Biztalk, Windows Workflow Foundation, ASP.NET 2.0 en nog veel meer. Als je je nou verveelt, is dit wellicht eens leuk om te doen. Het kost niets!

Hier is de link: http://msdn.microsoft.com/virtuallabs/default.aspx

Een eerste blik op LINQ

Dennis Vroegop — Thu, 10 Nov 2005 22:10:00 GMT

Het is alweer enige tijd geleden dat ik iets over C# 3.0 geschreven heb, maar dat ga ik nu (min of meer) goedmaken. Ik vervolg deze serie nu met een aantal artikelen over een van de toepassingen van de nieuwe mogelijkheden: Linq.

Linq staat voor Language Integrated Query. Zoals de naam al aangeeft geeft ons dat de mogelijkheid om in de taal (in dit geval C# maar VB.Net kan er ook mee overweg) queries te definieren. Het verhaal achter het ontstaan van Linq zal ik hier even kort schetsen, zodat je een beeld hebt wat de geschiedenis is.

Neem eens een stuk code dat je recentelijk geschreven hebt. Kijk er eens goed naar en ga dan kijken hoe vaak je in die code "zoekt" naar zaken. Denk bijvoorbeeld aan het doorlopen van een ArrayList instance met daarin Customer objecten. Regelmatig schrijf je code die in die lijst op zoek gaat naar alle klanten die nog een betaling open hebben staan. Of je wilt een overzicht van alle klanten in je lijst die aangegeven hebben dat ze informatie per email willen ontvangen. Of je wilt simpelweg in die lijst op zoek gaan naar die ene klant met klantnummer 'xyz123' zodat je de gegevens daarvan op het scherm kunt tonen. Als je goed kijkt, zul je zien dat het zoeken naar gegevens in lijsten (in wat voor vorm dan ook) best vaak voorkomt.

Echter, een goede methode om te zoeken is er niet. Neem de volgende code eens:

// Initializeer de boel
Customer displayCustomer = null;
bool bFound = false;
int counter = 0;

// Zoek de juiste klant
while( (!bFound) && (counter < customerList.Count) ) {
    displayCustomer = (Customer)customerList[counter];
    if( displayCustomer.CustomerID == "xyz123" ) {
        bFound = true;
    }
    counter++;
}

if( bFound ) {
    // Laat zien
} else {
    // Geef foutmelding
}

// Enzovoorts...

Ik weet het, deze code kan beter. Je kunt natuurlijk een specifieke CustomerList type definieren, met daarin de juiste zoekcode. Maar die zal er niet echt anders uitzien dan bovenstaande code.

Zoeken is behoorlijk belangrijk de meeste, serieuze applicaties. Er zijn vele voorbeelden te verzinnen: zoeken naar de inlognaam van de gebruiker om zijn of haar wachtwoord te controleren, zoeken naar de bestanden in de plugin-directory, zoeken naar de geinstalleerde printers op het systeem, zoeken naar.. affijn, je snapt het wel.

Zoeken gebeurdt uiteraard ook in databases. Da's mooi, zul je denken, want daar hoef ik niet zo veel voor te doen. Alles wat ik moet doen is de juiste SQL code schrijven en de database regelt het zelf wel. Maar heb je je wel eens gerealiseerd dat dat eigenlijk een hele vreemde constructie oplevert? Je schrijft hele mooie, goed gedocumenteerde, door de compiler op alle details gecontroleerde C# of VB.Net code, vervolgens plak je daar een string (!!!) in met daarin een stuk code in een hele andere taal, namelijk SQL. Denk daar eens over na: in onze code staat opeens een niet te controleren, niet te compileren en dus niet te verifieren string met een andere programmeertaal daarin. Vreemd, vind je niet?

Als je nu veel met XML werkt (en wie doet dat tegenwoordig niet?) dan krijg je te maken met weer een hele andere manier van zoeken in data. Nu kun je met XQuery of XPath aan de gang gaan, of je itereert zelf over de elementen in je XML document heen en goet alles zelf.

Zoeken, zoeken en zoeken. We doen het nogal eens in onze applicatie, op heel veel verschillende en elkaar min of meer tegensprekende methodes. Om daar nu wat aan te doen, is het Project Linq geboren. Het idee hierachter is: laten we alle mogelijke manieren van zoeken (querien in slecht nederlands) nu eens onder de loep nemen en daar een uniforme, strongly typed, verifieerbare en compileerbare methode voor verzinnen. En dat hebben ze gedaan.

Al gauw bleek dat dat niet zo eenvoudig was en om dat op een goede manier te doen moest de taal C# en VB.Net aangepast worden. Welke aanpassingen dat zijn, heb je in mijn vorige postings kunnen lezen (ja ja, er zat een lijn in het verhaal!). Met die uitbreidingen is Linq mogelijk geworden. Ik zal nog even op een rijtje zetten welke nieuwe mogelijkheden er komen:

Type inferrence (var q = ....)
Extension methods
Initializers
Anonymous types
Lambda expressions

Met dit alles kunnen we bovenstaande code anders gaan schrijven, op een manier die ons behoorlijk bekend voor zal komen:

var displayCustomer = from customer in customerList
                      where customer.CustomerID == "xyz123"
                      select customer;

if (displayCustomer != null)
{
    // Laat zien
}
else
{
    // Geef foutmelding
}

En dit doet dus precies hetzelfde...

Laat je niet verwarren door de rare plaatsing van 'select', dit leg ik nog wel uit. Maar afgezien daarvan is dit 'gewoon' SQL in C# syntax. De enige aanpassing die ik gedaan heb is dat customerList nu geen ArrayList meer is maar een List<Customer>. Dat maakt echter voor mijn verhaal niets uit.

Laten we eens kijken hoe dit nou kan.

Je moet weten dat de namespace System.Query (waar Linq in is gedefnieerd) voornamelijk bestaat uit een aantal extension methods op het type IEnumerable<T>. Met andere woorden: alles wat de interface IEnumerable<T> implementeert heeft een aantal extra methods gekregen. Een van die methods is bijvoorbeeld Where(); Die zit er als volgt uit:

IEnumerable<T> IEnumerable.Where<T>((T) => bool : predicate)

Met andere woorden: de method Where heeft als resultaat een IEnumerable<T> en als argument de lambda expression (T) => bool: predicate, oftewel er wordt een anonymous method gemaakt die een bool terug geeft. Dus als we dat even toepassen op onze customerList gaat dat er als volgt uitzien:

var resultList = customerList.Where( (Customer c) => c.CustomerID == "xyz123" );

Vertaling: neem onze List<Customer> customerList (welke IEnumerable<Customer> implementeert). Voer daar de 'Where' method op uit. In die Where method geven we mee de lambda expressie (nogmaals, lees mijn vorige postings over dit onderwerp om te begrijpen wat dat precies is) (Customer c) => c.CustomerID == "xyz123" . Er wordt nu dus een anonymous method gedefnieerd die voor iedere Customer instance in de lijst kijkt naar de CustomerID en die vergelijkt met "xyz123". Daar komt een bool uit (true of false) en als hij true is, dan wordt die Customer instance aan de nieuwe resultList toegevoegd. Overigens is resultList ook een class die IEnumerable<T> implementeert....

Kijk hier nog eens goed naar, laat het even bezinken. Ik wacht wel even.

Goed. Het resultaat is dus een IEnumerable<T>. Daarop kunnen we dan weer andere extension methods toepassen, welke bijna allemaal een IEnumerable<T> terug geven. We kunnen dus een hele rij van dit soort methods aanroepen: Lijst.Where().Where().GroupBy().Select(); Anders weergegeven:

Lijst.Where().
Where().
GroupBy().
Select();

Nou hebben we net gezien in mijn voorbeeld dat we helemaal geen IEnumerable<T>.Where() method gebruiken. Nee, we roepen gewoon from type x in lijst where x.iets == "bla" select x.ID; of zo iets dergelijks. De reden dat dat werkt is door het gebruik van Expression Trees. Dat is wellicht iets voor andere posting, maar neem nu maar even van me aan dat dat er voor zorgt dat onze mooie, SQL-achtige syntax verandert in die reeks van method calls en dat alle code achter bijvoorbeeld de where vertaalt wordt in een lambda expressie. Moeilijk is dat niet, het is een kwestie van haakjes en dergelijke toevoegen.

Dat betekent dat onze eerste voorbeeld code er eigenlijk zo uit gaat zien:

var displayCustomer = customerList
.Where((Customer customer) => customer.CustomerID == "xyz123")
.Select(customer => customer);

En deze code moet nu te begrijpen zijn.

Je ziet het: als je er even naar kijkt, is het op zich vrij logisch. Maar je moet er even aan wennen. Persoonlijk vind ik mijn eerste Linq voorbeeld qua code duidelijker en overzichtelijker dan mijn eerst code-voorbeeld in deze posting.

Volgende keer ga ik kijken naar DLinq, oftewel Linq'en op een database. Het zal je niet verbazen dat dat vrijwel hetzelfde werkt als wat ik je nu heb laten zien.

Tot dan!

PS Mocht je opmerkingen, vragen of iets anders te melden hebben, aarzel dan niet om te reageren, hetzij via het commentaarvakje, hetzij via de mail. Op die manier weet ik of er uberhaupt mensen geinteresseerd zijn in wat ik te melden heb over dit onderwerp.

Sorry, sorry, sorry...

Dennis Vroegop — Tue, 25 Oct 2005 21:33:00 GMT

Ik had beloofd om een stukje van (D/X)Linq te laten zien. En dat heb ik dus nog niet gedaan. De reden daarvoor is dat ik het erg druk heb gehad, onder andere met het voorbereiden van mijn praatje voor de Nederlandse .NET gebruikersgroep, over hetzelfde onderwerp.

Het goede nieuws is dat ik nu nog beter weet wat ik jullie over C# 3.0 en Linq wil vertellen en ook hoe ik dat moet doen! Dus de rest van de artikelen worden nog beter!

Overigens: voor diegenen die niet kunnen wachten tot ik alles klaar heb en hier geplaatst heb, heb ik hier een link naar de officiele site van Linq. Daarop staan diverse whitepapers en de preview-compiler, zodat je er zelf mee aan de gang kunt gaan.

Tot die tijd! Veel plezier en happy coding!

Oude wijn in nieuwe zakken? Lambda expressies! (De toekomst van C#, deel 5)

Dennis Vroegop — Sun, 09 Oct 2005 20:21:00 GMT

Lambda expressies

Lambda expressies zijn niets nieuws. De eerste publicatie over 'lambda calculus' dateert uit de jaren dertig, dat is dus ver voordat men na begon te denken over C#. Lambda expressies vormen een belangrijk onderdeel van de taal Lisp maar zijn ook in andere omgevingen terug te vinden. Voor een overzicht van de Lambda calculus, zie deze entry in Wikipedia. Voor ons is het genoeg om te weten dat een Lambda expressie een andere schrijfwijze voor een functie is. Ik zal een voorbeeld geven:

Neem de wiskundige functie die een getal met zichzelf vermenigvuldigt: f(x) = x * x. In de lambda notatie wordt dat ? x. x * x. In C# drukken we dat uit als (int x) => x * x;

Let op: dit is geen compileerbare code, dit is slechts een schrijfwijze van een functie!

Een ander voorbeeld is bijvoorbeeld een functie die twee doubles bij elkaar optelt en het resultaat teruggeeft: (double x, double y) => return x + y;

We kunnen deze schrijfwijze gebruiken om de anonymous methods uit C# 2.0 te vereenvoudigen. Neem bijvoorbeeld de method List.FindAll(). Deze method ziet er als volgt uit:

public List List.FindAll(Predicate match) { ... }

De Predicate staat voor een delegate:

public delegate bool Predicate(T obj);

In het kort komt dit dus op het volgende neer: aan FindAll geef je een delegate mee, welke wordt aangeroepen voor ieder item T in de List. In de delegate kijk je of het meegegeven item voldoet aan een bepaalde eis, en je geeft true of false terug, al naar gelang de uitkomst. Hoewel deze functionaliteit nieuw is in C# 2.0, zal ik eerst even laten zien hoe je hem zou moeten gebruiken zonder anonymous methods:

List<string> lijst = new List<string> { "Dit", "is", "een", "verzameling", "strings" };

List<string> newLijst = lijst.FindAll(ValidateString);
foreach( string s in newLijst ) {
Console.WriteLine(s);
}

De delegate ValidateString ziet er als volgt uit:

public static bool ValidateString(string s) {
return (s.Length > 3);
}

Met andere woorden: we lopen door een lijst van strings heen, en geven een subset daaruit terug, bestaande uit strings met een lengte van meer dan 3. Het resultaat zal dan ook zijn "verzameling" en "strings".

In C#2.0 hebben we anonymous methods. Dit betekent dat we bovenstaande code kunnen schrijven zonder de ValidateString() method te maken. Dat gaat als volgt:

List<string> lijst = new List<string> { "Dit", "is", "een", "verzameling", "strings" };

List<string> newLijst = lijst.FindAll(delegate(string s) { return (s.Length > 3);});
foreach( string s in newLijst ) {
Console.WriteLine( s );
}

Zoals je ziet hebben we de delegate niet meer nodig: de code daarvoor staat in de lijst.Findall() aanroep. Uiteraard is dit alleen handig indien de code in de delegate niet al te groot is; anders kun je beter een aparte method gebruiken.

In C# 3.0 kunnen we dit nog vereenvoudigen, met behulp van type inferrence en lambda expressions:

var lijst = new List<string> { "Dit", "is", "een", "verzameling", "strings" };

var newLijst = lijst.FindAll((string s) => (s.Length > 3));
foreach( var s in newLijst ) {
Console.WriteLine( s );
}

Door het gebruik van het 'var' keyword en de lambda expressie(string s) => (s.Length > 3)is de code een stuk overzichtelijker geworden.

Dit is voorlopig de laatste posting over de nieuwe features in de taal C# 3.0. Volgende keer zal ik alles wat ik in de afgelopen 5 postings gedemonstreerd heb samenvoegen in een overzicht van Linq.

Even in het kort: Linq staat voor Language Integrated Query, een manier om queries op te bouwen in je C# code. Dit is mogelijk doordat C# uitgebreid is met alle mogelijkheden die ik tot nu toe heb laten zien.

Dus als je je afvraagt waar dit hele verhaal naar toe gaat, hou mijn blog in de gaten en zie het allemaal samen komen in mijn bespreking van Linq, DLinq en XLing!

Nog meer tijdsbesparing (De toekomst van C#, deel 4)

Dennis Vroegop — Sat, 08 Oct 2005 19:52:00 GMT

Dit keer ga ik het hebben over 2 onderwerpen die nieuw zijn in C# 3.0. Die twee dingen zijn: initializers en anonymous types.

Initializers

Laat ik beginnen met een code-voorbeeld:

class Point {
    private int _x;
    private int _y;

    public int X {
        get { return _x; }
        set { _x = value; }
    }

    public int Y {
        get { return _y; }
        set { _y = value; }
    }
}

Als we in onze code nu een instance willen maken van Point, dan doen we dat dus zo:

Point myPoint = new MyPoint();
myPoint.X = 42;
myPoint.Y = 32;

Natuurlijk kunnen we een extra constructor maken die de waardes van X en Y instelt, maar in C# 3.0 kan dat ook op een andere manier. Dat ziet er dan zo uit:

Point myPoint = new Point{X=42, Y=32};

En dat maakt het leven een stuk overzichtelijker! Overigens hoef je niet alle properties of public fields mee te geven, alleen de X bijvoorbeeld had ook gekund. Ook de volgorde maakt niet uit, de velden zijn immers benoemd dus de compiler vindt wel waar alles heen moet.

Dit trucje kunnen we ook uithalen met Collections. Het is bekend dat we bijvoorbeeld een array direct kunnen vullen bij het declareren van de variabele:

string[] stringArray = { "Dit", "zijn", "een", "stelletje", "strings." );

Dat kan nu dus ook met collection classes. Eerst even de pre-c# 3.0 code:

List<string> stringList = new List<string>();
stringList.Add("Dit");
stringList.Add("zijn");
stringList.Add("een");
stringList.Add("stelletje");
stringList.Add("strings.");

Ziet er bekend uit, niet waar? Een hoop werk, en nogmaals: daar houden we niet zo van. Dus in C#3.0 ziet het er als volgt uit:

var stringList = new List<string>{"Dit", "zijn", "een", "stelletje", "strings." };

Dat is een stuk korter, overzichtelijker en duidelijker. Let ook op het gebruik van de 'var'. De compiler kan hier immers aan de new List afleiden wat stringList voor een type moet zijn, dus dat hoeven we niet nog een keer aan te geven.

Anonymous types

We hebben gezien hoe we een object makkelijker kunnen instantieren. Kijk nu eens naar de volgende code:

var someType = new {Naam="Dennis", EMail="dvroegop@detrio.nl", Huisnummer=42, Salaris=7800.00};

Dit is uiteraard een fictief voorbeeld: dat salaris ligt in werkelijkheid een stukje hoger.

Een quiz. Wat voor een type is sometype? Als het goed is, kan de compiler zelf bepalen wat voor een type het is, door te kijken wat er na de '=' staat. Dat is immers wat het 'var' keyword betekend. Maar... er staat niet zo veel achter het '=' teken, behalve het 'new' keyword en een initializer. Wat voor een type is dit nou?

Het antwoord daarop is: maakt dat wat uit? Ik kan je wel vertellen dat de compiler nu een class aanmaakt, maar hoe die precies heet weten we niet. De code die de compiler nu genereert ziet er ongeveer als volgt uit:

class __newType {
    private string _Naam = "Dennis";
    private string _EMail = "dvroegop@detrio.nl";
    private int _Huisnummer = 42;
    private double _Salaris = 7800.00;

public string Naam {
      get { return _Naam; }
      set { _Naam = value; }
}

public string EMail {
      get { return _EMail; }
      set { _EMail = value; }
}

public int Huisnummer {
      get { return _Huisnummer; }
      set { _Huisnummer = value; }
}

public double Salaris {
      get { return _Salaris;}
      set { _Salaris = value; }
}
}

en even verderop:

__newType someType;
someType = new __newType();

De waardes hoeven niet meer geinitialiseerd te worden, die staan immers in de class. In werkelijkheid ziet het er iets anders uit, maar voor dit moment is dit goed genoeg. Er wordt dus een anoniem type aangemaakt waarvan we de naam niet kennen, maar hij wordt wel aangemaakt met de juiste velden er in. Dus na de uitbreiding met anonymous methods in C#2.0 hebben we nu zelfs anonymous types. Voor je het weet komen ze met anonymous applications, maar dat zal wel niet zo snel gebeuren.

Volgende keer: lambda expressions!

Laten we gaan uitbreiden! (De toekomst van C# deel 3)

Dennis Vroegop — Fri, 07 Oct 2005 22:25:00 GMT

Heb jij dat nou ook wel eens? Je krijgt van een collega een assembly met daarin een aantal classes die je in je eigen C# applicatie moet gaan gebruiken. En die classes zijn best ok, maar als ze nou net dat ene stukje functionaliteit erbij zouden hebben, of net die ene method zouden ondersteunen, dan zouden ze fantastisch zijn. Maar ja... binnen je organisatie ben jij de enige die fantastische code oplevert en de rest is maar zo-zo, dus die assembly is niet precies wat je nodig hebt.

Lastig.

Nou hoeft dat in theorie in een object georiënteerde taal als C# helemaal geen probleem te zijn. Immers, een van de voordelen van OO is dat alles herbruikbaar en uitbreidbaar is. Je neemt de class van je collega, leidt er een subclass van af, voegt de juiste functionaliteit aan toe en je bent klaar! Of toch niet?

Nou nee. Het werkt wel zo, maar het is niet de meest praktische methode. Tenminste, niet altijd. Neem bijvoorbeeld de volgende classes:

namespace LameClasses {
    public abstract class Person {
        // some stuff
    }

    public class Customer : Person {
        // other stuff
    }

    public class Employee : Person {
        // and yet more stuff
    }
}

Allemaal leuk en aardig, maar in jouw applicatie heb je code nodig die wat statistische gegevens ophoest van Employee en van Customer. De plek om dat te doen is uiteraard in Person, maar wat als je daar niets aan kunt veranderen? Heb je bijvoorbeeld alleen de dll gekregen en niet de source-code? Of heb je wel de source-code erbij gekregen maar wordt de assembly op dat moment ook door anderen, die geen behoefte hebben aan jouw statistische code, gebruikt? In dat soort gevallen kun je Person niet aan gaan passen. Dus krijg je de volgende code:

namespace ReallyCoolStuff {
    public class CoolCustomer: Customer {
        public void DoSomeExcitingCode() {
            // Put your brilliant code here
        }
    }

    public class CoolEmployee : Employee {
        public void DoSomeExcitingCode() {
            // Put the same brilliant code here again
        }
    }
}

Tja... dit is ook geen oplossing, je bent immers dezelfde code twee keer aan het toevoegen. Ok, je kunt een derde class introduceren met daarin de code, en die code dan aanroepen vanuit CoolCustomer en CoolEmployee. Maar als iemand anders nou weer iets toe wil voegen? Krijgen we dan de class EvenCoolerCustomer, EvenCoolerEmployee enzovoorts? Ik hoop het toch niet!

Nog even het probleem samengevat: hoe kan ik een class uitbreiden zonder aan de code van de originele class te komen en toch de nieuwe code zo duidelijk en toegankelijk mogelijk houden?

Het C# team heeft daar een antwoord op: extensions.

Kort gezegd: extensions zijn methods van een class die buiten die class gedefinieerd zijn. Dat werkt als volgt. Denk nog even terug aan ons voorbeeld van Customer en Employee. We moeten daar dus een method DoSomeExcitingCode() aan toevoegen. Om dat te doen in C# 3.0, maak je een nieuwe static class aan (hij moet static zijn!) in een of andere namespace (maakt niet uit welke):

namespace MyExtensions {
public static class MyExtensionClass {
}
}

Zo iets dus. Het maakt eigenlijk niet zo veel uit hoe de class heet, als je je maar aan de coding standards houdt die jouw organisatie hanteert. In deze class definieer je de methods die je aan de niet-perfecte classes wilt toevoegen. Zo dus:

namespace MyExtensions {
    public static class MyExtensionClass {
        public static void DoSomeExcitingCode() {
            // Ah.. mijn briljante code is weer terug!
        }
    }
}

Tot zover niets spannends, toch? Maar dit gaat niet werken. Nou ja, het gaat wel werken, maar het is nog geen extension. Om deze method nou aan de Person class toe te voegen (en dat willen we immers) moeten we de signature enigzins aanpassen:

namespace MyExtensions {
    public static class MyExtensionClass {
        public static void DoSomeExcitingCode(this Person person) {
            // Doe hier iets met person...
        }
    }
}

In de body van DoSomeExcitingCode kun je nu aan de slag gaan met person. Maar nu wordt het leuk: zorg ervoor dat de alle namespaces in de using clause heb staan (in mijn voorbeeld dus LameClasses en MyExtensions) en dan:

var medewerker = new Employee();
// En hier komt de magie:
medewerker.DoSomeExcitingCode();

(als je die 'var' niet begrijpt, lees dan mijn vorige posting in mijn blog)

Mmmm.. We roepen DoSomeExcitingCode() aan op het object medewerker, van de class Employee, maar... in de definitie van Employee komt die hele method niet voor! Nee, dat klopt dus. Met het gebruik van 'this Person person' in de parameter lijst van de extension method hebben we aangegeven dat deze method gebruikt mag worden bij alle instances van Person (of afgeleiden!)

Let echter op: het is erg verleidelijk om dit soort code te gaan schrijven:

public static class SuperExtensions {
public static string[] GetAllPrivateFields(this object obj) {
// Ga met reflection door alle private fields heen en geef
// die terug in de string[]... :(
}
}

En nu kun je in alle code, waar je de namespace in je using heb staan waar deze class in staat, GetAllPrivateFields() aanroepen. Want je hebt een uitbreiding op object gemaakt, en aangezien alles van object (inclusief int, bool, char enzovoorts!!!) is afgeleid kun je nu overal deze method toepassen!

Dat komt de leesbaarheid en onderhoudbaarheid van je code niet ten goede. Dus gebruik extensions spaarzaam!

Volgende keer meer over nog meer mogelijkheden in C# 3.0!