Dankwoord - martes

3.3. NAÏEVE AANPAK 39
Listing 30 voorbeeld operatie met pre- en postcondities
context ClassA :: operation1() :
pre pre1:
pre pre2:
post post1:
Voor elke pre- en postconditie zullen we een aparte booleaanse methode genereren. Daarna
voegen we de pas gegenereerde pre- en postconditiemethoden in in de juiste plaatsen van onze
operatie. Voor precondities is dat in het begin van de operatie. Voor postcondities is dat op
het einde van deze operatie. Het invoegen van deze code gebeurt door de assert constructie
die we in het begin van dit hoofdstuk besproken hebben.
De naam van elke pre- en postconditiemethode is geconcateneerd met de naam van de preof
postconditie die ze voorstellen en met de naam van de operatie waartoe ze behoren. Dat
zorgt voor unieke namen van methoden en lost het probleem van name clashes op.
De JAVA code ziet er als volgt uit:
Listing 31 Sjabloon voor pre- en post-condities bij de naïeve aanpak
operation1(){
assert(checkAllInvariants());
assert(checkPrePre1Operation1());
assert(checkPrePre2Operation1()) ;
//
// body of operation
//
assert(checkPostPost1Operation1());
assert(checkAllInvariants());
}
private boolean checkPrePre1Operation1(){
return ;
}
private boolean checkPrePre2Operation1(){
return ;
}
private boolean checkPostPost1Operation1(){
return ;
}
We moeten ook niet vergeten dat bij operaties klasse-invarianten ook gecontroleerd moeten
worden alhoewel ze niet opgenomen zijn in de operatie. De controle op invarianten moet
voor en na de uitvoering van elke publieke methode en na de uitvoering van elke constructor
gebeuren. Bijgevolg moeten we een assertie van alle invarianten toevoegen. Dat is te zien in
de eerste en laatste regel van de JAVA vertaling voor de operation1() methode.