visual basic 2010 broncode voorbeelden

Specifiek voor een aantal programmeertalen zijn de Property constructies.  Deze vervangen de get-function en/of de set procedure ( en worden ook zo op de achtergrond vertaald ) :

John

De getter (1) van de property wordt uitgevoerd wanneer de property wordt uitgelezen (4).  De setter (2) wordt uitgevoerd bij het instellen van de property waarde (3).  De toegekende waarde ( hier de String literal "John" ) wordt ge-assigneerd aan de argument variable value van de setter.

Zoals je merkt is de implementatie van de getter en setter identiek aan respectievelijk de get functie en set procedure uit volgend voorbeeld.
Beide voorbeelden bevatten een gelijke abstratie van een persoon, een persoon heeft een naam, die men kan instellen en opvragen.

Anders is wel het gebruik voor de client.  Deze client kan de property nu aanspreken alsof het een publiek veld zou betreffen van dat object.
De toekenning aan deze property (3) gebeurt op dezelfde wijze als een toekenning aan een String variabele.
Het uitlezen van de property (4) vormt hier een String expressie, net zoals de aanroep naar de get functie uit vorig voorbeeld.  Dit maakt ook duidelijk dat het hier een String expressie zal zijn die als returnwaarde wordt opgegeven in de getter van de property.

De argumentvariabele van de setter krijgt by default de identifier value, dit kan aangepast worden, maar hier is echter geen reden toe.
Wat niet aangepast kan worden, of wat steeds gelijk moet zijn, is het type vermeld in de As clausule van de signatuurregel van de property zelf en het type vermeld in de As clausule van de signatuurregel van de setter ( in bovenstaand voorbeeld dus beide String ).

John

Ook via een publiek veld kunnen we in de client op dezelfde wijzen een eigenschap inlezen of uitlezen :

Some Title

Het voordeel van het werken met een Property constructie is echter dat er nu binnen de implementatie van de getter en de setter ruimte is voor validatie.
De getter kan bijvoorbeeld de inhoud van het veld ( gebruikt voor de opslag van de eigenschap ) valideren ( en/of bewerken ) alvorens de terugkeerwaarde in te stellen.  De setter kan dan bijvoorbeeld de toegekende waarde ( inhoud van value ) valideren ( en/of bewerken ) alvorens het gerelateerde veld op te vullen.

Validatie is natuurlijk geen specifiek kenmerk voor de Property constructie, ook in getfunctions en setprocedures kan gelijkaardige validatie gebeuren.

Velden worden zelden publiek gemaakt.  Deze zijn immers doorgaans louter noodzakelijk om een toestand te bewaren.  Het bewaren van een toestand is een implementatiekwesties.  En implementatiekwesties worden steeds ingekapseld.

Tot en met versie 2005 waren er weinig significante voordelen van het gebruik van properties in tegenstelling tot het gebruik van get functions en set procedure.  De keuze voor een van beide was dan ook vooral afhankelijk van de voorkeur van de auteur van de klasse.
Sedert Visual Basic 2008 biedt het gebruik van properties in tegenstelling tot het gebruik van set procedures en get functies meerdere voordelen.
Verschillende design coding guidelines geven aan dat men properties gebruikt indien je rechtstreekse werkt op een ingekapseld veld die de respresentatie van deze eigenschap verwezelijkt en anderzijds getfuncties en setprocedures gaat gebruiken indien de implementatie complexer is ( en een langere uitvoeringstijd nodig heeft ) dan het rechtstreekse gebruik van een ingekapseld veld.

Bemerk dat de identifier van Propertys doorgaans zelfstandig-naamwoorden ( bijvoorbeeld Name ) zullen zijn, in tegen stelling tot methods die doorgaans een werkwoord of een combinatie van een werkwoord en een zelfstandig-naamwoord ( bijvoorbeeld GetName, SetName, ... ) zullen zijn.

De access modifier van enkel de getter of enkel setter van een property kan beperkt worden ( bijvoorbeeld Private in plaats van Public ) ten aanzien van de property zelf.

Hieronder beschikt een Counter klasse over een publieke Value property met een ingekapselde setter (1) :

Binnen de klasse zelf kan Value zowel uitgelezen als ingelezen worden (2), alle members van een klasse ( of ze nu ingekapseld zijn of niet ) zijn immers beschikbaar binnen de klasse zelf.

Zoals hieronder gedemonstreerd, is het voor clients niet mogelijk om de setter van de property Value te gebruiken (3).

0
1
2

Men bekomt hier voor client als het ware een "readonly" eigenschap.  Binnen de klasse zelf is de property echter wel "writeable".

Abstractiegewijs komt het zelden voor dat getters worden ingekapseld wanneer de setter publiek toegankelijk is.