Geavanceerde methodetechnieken
Nu we methoden in de vingers krijgen, is het tijd om naar enkele gevorderde aspecten te kijken. Je hebt vermoedelijk al door dat methoden een erg fundamenteel concept zijn van een programmeertaal en dus hoe beter we ermee kunnen werken, hoe beter.
Named parameters
Wanneer je een methode aanroept is de volgorde van je actuele parameters belangrijk: deze moeten meegeven worden in de volgorde zoals de methode ze verwacht.
Met behulp van named parameters kan je echter expliciet aangeven welke actuele parameters aan welke formele parameter moet meegegeven worden.
Stel dat we een methode hebben met volgende signatuur:
Zonder named parameters zou een aanroep van deze methode als volgt kunnen zijn:
We kunnen named parameters aangeven door de naam van de parameter gevolgd door een dubbel punt en de waarde. Als we dus bovenstaande methode willen aanroepen kan dat ook als volgt met named parameters:
of ook:
Kortom, op deze manier maakt de volgorde van parameter niets uit. Dit werkt echter enkel als je alle parameters op deze manier gebruikt.
Named en unnamed mixen: volgorde wél belangrijk
Je mag echter ook een combinatie gebruiken van named en gewone parameters, maar dan is de volgorde belangrijk: je moet je dan houden aan de volgorde van de methode-signatuur. Je verbetert hiermee de leesbaarheid van je code, maar krijgt niet het voordeel van een eigen volgorde te hanteren. Enkele geldige voorbeelden:
Enkele niet geldige voorbeelden:
Optionele parameters
Soms wil je dat een methode een standaardwaarde voor een parameter gebruikt indien de programmeur in z'n aanroep geen waarde meegaf. Dat kan met behulp zogenaamde van optionele of default parameters. Je geeft aan dat een parameter optioneel is door deze een default waarde te geven in de methode-signatuur. Deze waarde zal dan gebruikt worden indien de parameter geen waarde van de aanroeper heeft gekregen.
Let op: Optionele parameters worden steeds achteraan de parameterlijst van de methode geplaatst.
In het volgende voorbeeld maken we een nieuwe methode aan en geven aan dat de laatste twee parameters (optName
en age
) optioneel zijn door er met de toekenningsoperator een default waarde aan te geven:
Wanneer nu een parameter niet wordt meegegeven, dan zal deze default waarde in de plaats gebruikt worden:
De inhoud van argumenten wordt bij iedere aanroep:
Lijn 1
15
"tim"
25
Lijn 2
20
"dams"
10
Lijn 3
35
"unknown"
10
Je mag enkel de optionele parameters van achter naar voor weglaten. Volgende aanroep is dus niet geldig:
Met optionele parameters kunnen we dit omzeilen. Volgende aanroep is wel geldig:
Method overloading
Method overloading wil zeggen dat je een methode met dezelfde naam en returntype meerdere keren definieert maar met andere formele parameters qua datatype en/of aantal. De compiler zal dan zelf bepalen welke versie moet aangeroepen worden, gebaseerd op het aantal en type actuele parameters dat je meegeeft.
Volgende methoden zijn overloaded:
Afhankelijk van de aanroep zal dus de ene of andere methode uitgevoerd worden. Volgende code zal dus werken:
Betterness rule
Indien de compiler twijfelt tijdens de overload resolution zal de betterness rule worden gehanteerd: de best passende methode zal aangeroepen worden.
Stel dat we volgende overloaded methoden hebben:
Volgende aanroepen zullen dus als volgt uitgevoerd worden, gebaseerd op de betterness rule:
Volgende tabel geeft de betternes rule weer. In de linkse kolom staat het datatype van de parameter die wordt meegegeven. De rechtse kolom toont welk datatype het argument in de methodesignatuur meer voorkeur heeft van links naar rechts indien dus het originele type niet beschikbaar is.
byte
short, ushort, int, uint, long, ulong, float, double, decimal
sbyte
short, int long, float, double, decimal
short
int, long, float, double, decimal
ushort
int, uint, long, ulong, float, double, decimal
int
long, float, double, decimal
uint
long, ulong, float, double, decimal
long
float, double, decimal
ulong
float, double, decimal
float
double
char
ushort, int, uint, long, ulong, float, double, decimal
Als je bijvoorbeeld een parameter van het type int
meegeeft bij een methode-aanroep (eerste kolom), dan zal een methode waar het argument een long
verwacht geprefereerd worden boven een methode die voor datzelfde argument een float
verwacht, enz.
Indien de betterness rule niet werkt, dan zal de eerste parameter bepalen wat er gebruikt wordt. Dat zien we in volgende voorbeeld:
Indien ook die regel niet werkt dan zal volgende foutmelding verschijnen:
Methoden debugen met step-in
Herinner je je dat ik in hoofdstuk 4 debuggen uitlegde en zei dat we één knopje later gingen bekijken? Wel die tijd is nu gekomen. Tijd om de step in knop toe te lichten.
Wanneer je een breakpoint zet in je code en in debugermode komt dan kan je doorheen je code stappen, wat je hopelijk al geregeld hebt gedaan. Het nadeel was dat je niet in een methode ging wanneer je daar over stapte. Wel, met de "step in" knop kan je dat nu wel. Wanneer je aan een lijn met een eigen geschreven methode komt dan zorgt deze knop ervoor dat je in de methode gaat en vervolgens daar verder kunt stappen over de verschillende lijnen code.
Het klinkt simpel, maar oefen het toch best een paar keer!
Last updated