Nou, ik ben er toch wel wat op teruggekomen. Ik ben tegen een paar dingen aangelopen die me niet zo bevallen. Properties, bijvoorbeeld. Daarover zal ik vandaag klagen. Later zal ik over delegates en events klagen.
Wat is een property? Het is iets dat het midden houdt tussen een method (een aktie) en een field (een waarde). Stel dat je een class hebt die een AGV representeert. Die zou bijvoorbeeld een method ‘GaRijden’ kunnen hebben, en ‘GaLinksaf’ en ‘Stop’ et cetera. En de class zou als fields onder meer ‘Snelheid’ en ‘ContainerGewicht’ kunnen hebben.
agv.GaRijden();
agv.GaLinksaf();
System.Console.WriteLine("snelheid is " + agv.Snelheid + " m/s");
Een property is, zoals gezegd, iets dat het midden houdt tussen een method en een field. Je gebruikt 'm alsof 't een field is, maar in werkelijkheid roep je met het opvragen en instellen een stukje code aan. Je zou bijvoorbeeld een property voor het opvragen van de positie kunnen maken:
Systeem.Console.WriteLine("positie is " + agv.Positie);
In de AGV-class zou dat er zo uit kunnen zien:
public Coordinates Positie {
get {
// zet de GPS-ontvanger aan
// wacht op een locatie-fix
// return de positie
}
}
Er gebeurt nogal wat bij het ophalen van de positie, maar dat zie je niet. Dus je weet niet wat je allemaal teweeg brengt. Dit soort constructies is dan ook niet zo slim. Microsoft zelf zegt daarover:
“Properties are used like fields, meaning that properties should not be computationally complex or produce side effects.”
Zoals eerder vermeld zijn niet alle IT-professionals in staat om goed werk te leveren. Dus ik reken er maar niet op dat deze eigenschap van C# altijd goed gebruikt wordt.
En wat voegen properties eigenlijk toe? Je kan ze altijd vervangen door (zonodig) een private field (die de waarde bevat), gecombineerd met gewone get- en/of set-methods.
Geen opmerkingen:
Een reactie posten