Methoden en access modifiers
We zullen nu enkele basisconcepten van klassen en objecten toelichten aan de hand van praktische voorbeelden.
Object methoden
Stel dat we een klasse willen maken die ons toelaat om objecten te maken die verschillende mensen voorstellen. We willen aan iedere mens kunnen zeggen "Praat eens".
We maken een nieuwe klasse Mens
en plaatsen in de klasse een methode Praat
:
We zien twee nieuwe aspecten:
Het keyword
static
mag je niet voor een methode signatuur zetten (later ontdekken we wanneer dat soms wel moet) .Voor de methode plaatsen we
public
: dit is een access modifier die aangeeft dat de buitenwereld deze methode op het object kan aanroepen.
Je kan nu elders objecten aanmaken en ieder object z'n methode Praat
aanroepen:
Er zal twee maal Ik ben een mens!
op het scherm verschijnen. Waarbij telkens ieder object (joske
en alfons
) zelf verantwoordelijk was dat dit gebeurde.
Public en private access modifiers
De access modifier geeft aan hoe zichtbaar een bepaald deel van de klasse is. Wanneer je niet wilt dat "van buiten" een bepaalde methode kan aangeroepen worden, dan dien je deze als private
in te stellen. Wil je dit net wel dat moet je er expliciet public
voor zetten.
Test in de voorgaande klasse eens wat gebeurt wanneer je public
vervangt door private
. Inderdaad, je zal de methode Praat
niet meer op de objecten kunnen aanroepen.
Wanneer je geen access modifier voor een methode zet in C# dan zal deze als private
beschouwd worden. Dit geldt voor alle zaken waar je access modifiers voor kan zetten: niets ervoor zetten wil zeggen private
.
Volgende twee methoden-signaturen zijn dus identiek:
Het is een héél slechte gewoonte om géén access modifiers voor iedere methode te zetten. Maak er dus een gewoonte van dit steeds ogenblikkelijk te doen.
Test volgende klasse eens, kan je de methode VertelGeheim
vanuit de Main op joske
aanroepen?
Naast private
(het meest beschermd) en public
(het meest open) zijn er nog een aantal access modifiers die allemaal de toegang tot een klasse meer of minder kunnen inperken. Verderop in het boek zullen we nog protected
(enkel zichtbaar voor overgeërfde klassen) bekijken. Maar weet dat ook nog internal
(enkel binnen dezelfde assembly), protected internal
en private protected
bestaan. In dit boek gaan we ons beperken tot private
, protected
en public
. Je zal echter merken dat VS 2022 standaard met internal
werkt, wat voor ons niet echt uitmaakt.
Reden van private
Waarom zou je bepaalde zaken private
maken?
De code binnenin een klasse kan overal aan binnen de klasse zelf. Stel dat je dus een erg complexe publieke methode hebt, en je wil deze opsplitsen in meerdere delen, dan ga je die andere delen private
maken. Dit voorkomt dat programmeurs die je klasse later gebruiken, stukken code aanroepen die helemaal niet bedoeld zijn om rechtstreeks aan te roepen.
Volgende voorbeeld toont hoe je binnenin een klasse andere zaken van de klasse kunt aanroepen: we roepen in de methode Praat
de methode VertelGeheim
aan (die private
is voor de buitenwereld, maar niet voor de code binnen de Praat
-methode).
Als we nu elders een object laten praten als volgt:
Dan zal de uitvoer worden:
Met behulp van de dot-operator (.
) kunnen we aan alle informatie die ons object aanbiedt aan de buitenwereld. Ook dit zagen we reeds toen we een Random
-object hadden: we konden maar een handvol zaken aanroepen op zo'n object, waaronder de Next
methode.
Het is natuurlijk een beetje vreemd dat nu al onze objecten zeggen dat ze verliefd zijn op Anneke. Dit is niet het smurfendorp met maar 1 meisje! Dit gaan we verderop oplossen. Stay tuned!
Instantievariabelen
Voorlopig doen alle objecten van het type Mens
hetzelfde. Ze kunnen praten en zeggen hetzelfde. We weten echter dat objecten ook een interne staat hebben die per object individueel is (we zagen dit reeds toen we balletjes over het scherm lieten botsen: ieder balletje onthield z'n eigen richtingsvector en positie). Dit kunnen we dankzij instantievariabelen (ook wel datavelden of datafields genoemd) oplossen. Dit zullen variabelen zijn waarin zaken kunnen bewaard worden die verschillen per object.
Stel je voor dat we onze mensen een geboortejaar willen geven. Ieder object zal zelf in een instantievariabele bijhouden wanneer ze geboren zijn (het vertellen van geheimen zullen we verderop behandelen):
Enkele belangrijke concepten:
De instantievariabele
geboorteJaar
zetten we private: we willen niet dat de buitenwereld het geboortejaar van een object kan aanpassen. Beeld je in dat dat in de echte wereld ook kon. Dan zou je naar je kameraad kunnen roepen "Hey Adil, jouw geboortejaar is nu 1899! Ha!" Waarop Adil vloekend verandert in een steenoud mannetje.We geven de variabele een beginwaarde
1970
. Alle objecten zullen dus standaard in het jaar 1970 geboren zijn wanneer we deze metnew
aanmaken.We kunnen de inhoud van de instantievariabelen lezen (en veranderen) vanuit andere delen in de code. Zo gebruiken we
geboorteJaar
in de tweede lijn van dePraat
methode. Als je die methode nu zou aanroepen dan zou het geboortejaar van het object dat je aanroept mee op het scherm verschijnen.
We moeten ook dringend enkele extra niet-officiële identifier regels in het leven roepen:
Klassenamen en methoden in klassen beginnen altijd met een hoofdletter.
Alles dat
public
is in een klasse begint ook met een hoofdletter.Alles dat
private
is begint met een kleine letter (of liggend streepje), tenzij het om een methode gaat, die begint altijd met een hoofdletter.
Dit zijn geen officiële regels, maar afspraken die veel programmeurs onderling hebben gemaakt. Het maakt de code leesbaarder.
Niet doen. Simpel! Instantievariabele mogen NOOIT public
gezet worden. De C# standaard laat dit weliswaar toe, maar dit is één van de slechtste programmeerdingen die je kan doen. Wil je toch de interne staat van een object kunnen aanpassen dan gaan we dat via properties en methoden kunnen doen, wat we zo meteen gaan uitleggen. Zie dat ik hier niet te vaak tussenbeide moet komen. Dank!
Ok, we zullen maar luisteren naar meneer de agent. Stel nu dat we een verjongingsstraal hebben waarmee we het geboortejaar van de mensen steeds met 1 jaar kunnen verhogen (en ze dus een jaar jonger maken).
Zoals al gezegd: Ieder object zal z'n eigen geboortejaar hebben.
Die laatste opmerking is een kernconcept van OOP: ieder object heeft z'n eigen interne staat die kan aangepast worden individueel van de andere objecten van hetzelfde type. We zullen dit testen in volgende voorbeeld waarin we 2 objecten maken en enkel 1 ervan verjongen. Kijk wat er gebeurt:
Als je voorgaande code zou uitvoeren zal je zien dat het geboortejaar van Elvis verhoogd en niet die van Bono wanneer we StartVerjongingskuur
aanroepen. Zoals het hoort!
De uitvoer zal zijn:
Correct. Maar dat was dus maar een voorbeeld. De hoofdreden dat we instantievariabelen niet zomaar public
mogen maken is om te voorkomen dat de buitenwereld instantievariabelen waarden geeft die de werking van de klasse zouden stuk maken. Stel je voor dat je dit kon doen: adil.geboortejaar = -12000;
Dit kan nefaste gevolgen hebben voor de klasse.
Daarom gaan we de toegang tot instantievariabelen als het ware controleren door deze enkel via properties en methoden toe te laten. We zouden dan bijvoorbeeld het volgende kunnen doen:
Mooi he. Zo voorkomen we dus dat de buitenwereld illegale waarden aan een variabele kan geven (in dit geval kan dus niet voor 1900 geboren zijn). Objecten zijn verantwoordelijk voor zichzelf en moeten zichzelf dus ook beschermen zodat de buitenwereld niets met hen doet dat hun eigen werking om zeep helpt.
Andere lieven
We kunnen nu het probleem oplossen dat al onze mensen verliefd zijn op Anneke. Volgende code toont dit:
Nu kunnen we dus "Temptation Island - de OOP editie" beginnen:
De uitvoer van voorgaande code zal zijn:
Klasse "Studenten
" of "Student
"?
Veel beginnende programmeurs maken fouten op het correct kunnen onderscheiden wat de klassen en wat de objecten in hun opgave juist zijn. Het is altijd belangrijk te begrijpen dat een klasse weliswaar beschrijft hoe alle objecten van dat type werken, maar op zich gaat die beschrijving steeds over 1 object uit de verzameling. Say what now?!
Als je een klasse Student
hebt, dan zal deze eigenschappen hebben zoals Punten
, Naam
en Geboortejaar
. Als je een klasse Studenten
daarentegen hebt, dan is dit vermoedelijk een klasse die beschrijft hoe een groep studenten moet werken in je applicatie. Mogelijk zal je dan properties hebben zoals KlasNaam
, AantalAfwezigen
, enz. Kortom, eigenschappen over de groep, niet over 1 student.
"Level
" of "Level1
"?
Een andere veelgemaakte fout is klassen te schrijven, die maar exact één object kan en moet creëren (dit heet een singleton). Stel je voor dat je een spel maakt waarin verschillende levels zijn. Een logische keuze zou dan zijn om een klasse Level
te maken (niét Levels
) die properties heeft zoals MoeilijkheidsGraad
, HeeftGeheimeGrotten
, AantalVijanden
, enz.
Vervolgens kunnen we dan instanties maken: 1 object stelt 1 level in het spel voor. De speler kan dan van level naar level gaan en de code start dan bijvoorbeeld telkens de BeginLevel
methode:
Wat dus niet mag zijn klassen met namen zoals level1
, level2
, enz. Vermoedelijk hebben deze klasse 90% gelijkaardige code en is er dus een probleem met wat we de architectuur van je code zouden kunnen noemen. Of duidelijker: je snapt niet wat het verschil is tussen klassen en objecten! Objecten met namen zoals level1
en level2
zijn wél dus toegestaan, daar ze dan vermoedelijk allemaal van het type Level
zijn. Maar opgelet: als je variabelen hebt die een genummerd zijn (bv. bal1
, bal2
, enz.) dan is de kans groot dat je vervolgens een array van objecten nodig hebt (wat we in hoofdstuk 12 uit de doeken zullen doen).
Last updated