.NET Features: Object Initializer

Door Luuk1983 op woensdag 22 juni 2011 11:20 - Reacties (11)
Categorie: Programmeren, Views: 3.267

Als .NET-programmeur merk ik regelmatig dat andere programmeurs niet op de hoogte zijn van sommige handige en slimme features in het .NET framework die het programmeren een stuk makkelijker kunnen maken. Soms zijn deze features verstopt, of soms zijn ze pas nieuw, maar handig zijn ze altijd. Dit is deel 3 van een serie met kleine voorbeelden van features die je als .NET-programmeur (met name in C#) mogelijk nog niet kent. Deze keer: Object initializers in C#.

Ik zie nog veel programmeurs hun classes en bijbehorende properties op de volgende manier declareren:
C#:
1
2
3
var foo = new Foo();
foo.ABoolean = true;
foo.AnIntegerValue = 1;

Dit is natuurlijk niet fout, maar het kan ook anders. Je kan het aanmaken van het object combineren met het zetten van de waardes. Dit heeft als voordeel dat je code (mogelijk) beter leesbaar wordt. Zeker als er maar weinig properties gezet hoeven te worden kan de object initialisatie plus het zetten van de properties op één regel.
C#:
1
var foo = new Foo {ABoolean = true, AnIntegerValue = 1};

Naar mijn mening verhoogt dit de leesbaarheid van de code. De functionaliteit is toegevoegd vanaf C#3.0 en is te gebruiken vanaf .NET3.5.

.NET Features: auto properties

Door Luuk1983 op dinsdag 21 juni 2011 14:44 - Reacties (9)
Categorie: Programmeren, Views: 3.180

Als .NET-programmeur merk ik regelmatig dat andere programmeurs niet op de hoogte zijn van sommige handige en slimme features in het .NET framework die het programmeren een stuk makkelijker kunnen maken. Soms zijn deze features verstopt, of soms zijn ze pas nieuw, maar handig zijn ze altijd. Dit is deel 2 van een serie met kleine voorbeelden van features die je als .NET-programmeur (met name in C#) mogelijk nog niet kent. Deze keer: auto properties in C#.

In het algemeen is het goed gebruik dat als je variabelen wilt ontsluiten gebruik te maken van public properties (naast functions natuurlijk) en geen public variabelen. Het was altijd veel werk om publieke properties te maken, omdat je dan altijd een achterliggende private variabele moest declareren om de waarde in vast te houden. Hoewel je met de refactor optie van Visual Studio niet alles helemaal zelf hoefde uit te typen, was het toch omslachtig.

Dit hoeft sinds .NET3.5/Visual Studio 2008 niet meer. Dit geldt overigens alleen voor 'simpele' properties waar je alleen een waarde aan wil kunnen toekennen en uitlezen. Als je meer dan dat wilt, dan gaat onderstaand verhaal niet op.

Voorheen moest je properties zo declareren:
C#:
1
2
3
4
5
6
7
8
9
10
public class Foo
{
    private int _anIntegerValue;

    public int AnIntegerValue
    {
        get { return _anIntegerValue; }
        set { _anIntegerValue = value; }
    }
}

Sinds .NET3.5/Visual Studio 2008 kan het veel korter:
C#:
1
2
3
4
public class Foo
{
    public int AnIntegerValue { get; set; }
}

Je hoeft niet perse meer een achterliggende private variabele aan te maken, dat gebeurt automatisch.

Overigens kan je de get en set nog steeds andere access-modifiers geven:
C#:
1
2
3
4
public class Foo
{
    public int AnIntegerValue { get; private set; }
}

(dank CyCloneNL voor de toevoeging)

Je mag niet alleen de get of de set expliciet implementeren en de ander impliciet. Dit kan dus niet:
C#:
1
2
3
4
5
6
7
8
9
10
public class Foo
{
    private int _anIntegerValue;

    public int AnIntegerValue
    {
        get;
        set { _anIntegerValue = value; }
    }
}


Maar nogmaals: dit verhaal geldt alleen voor 'simpele' properties, als je meer wilt dan een waarde opslaan en ophalen, dan heb je meer nodig dan bovenstaand verhaal.

Hopelijk hebben jullie er wat aan! Suggesties zijn altijd welkom.

.NET features: Optional Parameters

Door Luuk1983 op maandag 20 juni 2011 08:36 - Reacties (23)
Categorie: Programmeren, Views: 2.936

Als .NET-programmeur merk ik regelmatig dat andere programmeurs niet op de hoogte zijn van sommige handige en slimme features in het .NET framework die het programmeren een stuk makkelijker kunnen maken. Soms zijn deze features verstopt, of soms zijn ze pas nieuw, maar handig zijn ze altijd. Dit is deel 1 van een serie met kleine voorbeelden van features die je als .NET-programmeur (met name in C#) mogelijk nog niet kent. Deze keer: optional parameters in C#.

Optional Parameters zijn nieuw in .NET 4.0 voor C# en kunnen gebruikt worden om één functie met meerdere signatures te maken in plaats van meerdere overloaded functies. Deze functionaliteit is al langer beschikbaar in VB.NET. Een simpel voorbeeld van een paar overloaded functies:

C#:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
public void DoSomething()
{
    DoSomething(false, false);
}

public void DoSomething(bool bool1)
{
    DoSomething(bool1, false);
}

public void DoSomething(bool bool1, bool bool2)
{
    //Here code that does something
}


In .NET 4.0 kan dit samengevoegd worden tot één functie door middel van optional parameters. Je geeft dan aan welke properties optioneel zijn, waarna je ze niet perse hoeft in te vullen. Let wel op dat de optionele parameters altijd achteraan moeten komen te staan.

Je maakt parameters optioneel door ze een default waarde te geven:

C#:
1
2
3
4
public void DoSomething(bool bool1 = false, bool bool2 = false)
{
    //Here code that does something
}


Op dit moment zijn de volgende aanroepen naar bovenstaande functie geldig:

C#:
1
2
3
DoSomething();
DoSomething(false);
DoSomething(false,false);


Zoals je ziet zijn de drie overloaded functies aan het begin van deze blog nu vervangen door één functie met optionele parameters. Er is echter ook nog een belangrijk voordeel aan het gebruik van optional parameters: je hoeft niet perse alle optionele parameters in te vullen. Zo kan je in bovenstaand voorbeeld er ook voor kiezen om alleen de tweede parameter in te vullen en de eerste de default waarde te laten behouden:

C#:
1
DoSomething(bool2: true);


bool1 zal in dit geval zijn default waarde van false behouden en wordt alleen bool2 expliciet ingevuld.

Ik hoop dat jullie er wat aan hebben, of mochten er mensen zijn die nog wat aanvullingen hebben, dan hoor ik het graag.

Kopie van een kopie...

Door Luuk1983 op donderdag 11 november 2010 20:19 - Reacties (32)
Categorie: Hardware, Views: 5.957

Je kent het vast wel: kopieer een A4tje, kopieer het kopietje nog een keer en doe dat 10 keer en je ziet niet meer wat er nou eigenlijk op het origineel stond. Hoe zit dit nou eigenlijk met CD's en DVD's?

Ik had laatst een discussie met een vriend van me. Ik had een DVD met wat gegevens van een andere, gezamelijke vriend van ons gekopieerd en hij wilde deze DVD graag ook hebben. Even voor de beeldvorming: het origineel was een gebrandde DVD met wat gegevensbestanden erop, dus niet een geperste DVD met bijvoorbeeld een film. Toen ik mijn vriend voorstelde dat ik even een kopietje zou trekken merkte hij op dat hij liever een kopie van het origineel wilde hebben, omdat de kwaliteit anders minder zou kunnen zijn. Is dat eigenlijk zo?

Nou nee... En hierbij wil ik dat fabeltje meteen de wereld uit helpen. Bij alle digitale gegevens, maar vooral bij bestanden komt het allemaal erg nauw: elk bitje moet in principe in orde zijn, anders kan een programma corrupt raken of een bestand onleesbaar worden. DVD's en CD's hebben daarom een hoop partity gegevens op de disc staan: gegevens waarmee fouten en onleesbare sectoren geherconstrueerd kunnen worden tot op zekere hoogte. Was die foutcorrectie er niet, dan zou elk klein krasje op de disc kunnen bekenen dat de data corrupt is. CD's en DVD's bevatten eigenlijk altijd fouten, zelfs direct na het branden, maar de foutcorrectie zorgt ervoor dat alles prima leesbaar is.

En zolang de CD of DVD correct werkt kan er een kopie van gemaakt worden. De gegevens die van de CD of DVD worden gelezen zijn in principe foutloos: de gegevens die worden verkregen zijn gecorrigeerd door de foutcorrectie.. Eventuele fouten die bestaan op een kopie worden dus NIET meegekopieerd naar een volgende kopie. Het is zelfs mogelijk dat een kopie van betere kwaliteit is dan het medium waar het kopie van gemaakt is.

Misschien wisten jullie dit allemaal al, maar het leek me interessant om te delen. Mocht ik het ergens fout hebben, dan hoor ik het uiteraard ook graag.

GB / GiB: harddisk ruimtecrisis

Door Luuk1983 op dinsdag 26 oktober 2010 11:59 - Reacties (36)
Categorie: Hardware, Views: 5.828

Soms krijg je de discussie ineens weer: iemand heeft een Harddisk gekocht en komt er tot zijn verbazing achter dat de schijf ineens 'kleiner' is dan ze verwacht hadden. Meestal zijn het de harddiskfabrikanten die de schuld krijgen, terwijl het in feite Windows is die het verkeerd doet.

Je kent het verhaal wel: iemand koopt een harddisk en komt tot de conclusie dat in Windows de schijf ruim 7% kleiner is dan de schijf die ze gekocht hebben. In zekere zin is dit begrijpelijk, maar de verwarring ontstaat door inconsequent gebruik van de term 'GB'.

Op elke harddisk zal staan: 1GB = 1.000.000.000 bytes. En volgens de SI-standaard is dit correct: Giga betekent miljard, net als een gigahertz (1 miljard hertz) en gigawatt (1 miljard watt). Als er vanaf dag één afgesproken was dat we de SI eenheden zouden aanhouden, dan was er geen probleem geweest.

Echter, ICTers hebben vroeger SI-termen gekoppeld aan binaire aantallen. 2^10 bytes komt uit op 1.024 bytes en omdat dit dicht bij 1000 lag hebben ze er toen de term 'kilo' aangehangen. De kilobyte met in feite 'fout' gebruik van de term 'kilo' was geboren. 2^20 is 1.048.576 byte en werd megabyte en zo verder.

Omdat deze verwarring vaker de kop opstak, raadde de International Electrotechnical Commission aan om de 'afwijkende' kilo-, mega- en gigabyte respectievelijk kibibyte, mebibyte en gibibyte te noemen, met als afkortingen KiB, MiB en GiB.

1GB zou dus inderdaad gewoon 1.000.000.000 bytes moeten voorstellen. En dat is wat er mis gaat in Windows: windows geeft de grootte van schijven aan in GiB, maar noemt het GB. Dit kan zeer verwarrend werken. Enige troost is dat alle bestanden qua grootte berekend worden in GiB, zodat de grootte van alle bestanden ook 7% kleiner is dan dat je ze in GB berekend.

Maar hoe je het ook bekijkt, één ding is zeker: de discussie waar de harddisksmakers beschuldigd worden van mensen oplichten is pertinent onwaar.