Back on Form - so far..
Hah. Fifteen minutes of sorting out and everything in the program is fine again. And now I'm going to make a big backup onto a CD-ROM.....
Still got a cold though. But thanks to my superhuman strength I'm managing to keep on going almost as usual.
First year Java. Love it. Did methods today. Explained my views on defensive programming: "Always make sure that the sh*t falls on the other person's head". Explored this in terms of a method which adds an amount to the bar bill of a hotel customer when they pay for a drink:
boolean AddToBarBill ( int Amount ) {
// what do you put here to make sure that nobody can
// corrupt your bar bill...
}
Some nice problems: Consider the fact that a member of the bar staff and a guest might decide to attack your method and try and break it. If you let your users add negative numbers this means that naughty people could make their bill smaller. In an extreme case they could end up being paid for using the bar! So, stop them from adding negative numbers.
But then you have a problem with very big positive amounts. Because of the way that values are stored in computers a number can "wrap round" a bit like a car mileometer. So by adding carefully chosen positive values a naughty person could still make their bar bill smaller.
So, what you really do is ask the customer what the price range for drinks is, and then only allow prices amounts in this range to be added:
boolean AddToBarBill ( int Amount ) {
if ( ( Amount > MaxDrinkPrice ) ( Amount < MinDrinkPrice) )
{
return false;
}
else {
CustomerBill = CustomerBill + Amount;
return true;
}
}
This has two nice effects - it makes sure that your program always does the right thing and it makes it clear to the customer (i.e. the person who owns the hotel and is paying you to write the program) that it is their job to make sure that people in the bar enter the right prices - and that your program is doing the best it can to behave sensibly. The scary thing is that if you don't take these steps you may end up in court with your hotel customer (who has gone bankrupt) trying to take away all your money. It is interesting to see how a technical problem (stop someone from breaking my program) is really a specification problem (what do we mean by broken - and who has responsibility for breaking it).
Still got a cold though. But thanks to my superhuman strength I'm managing to keep on going almost as usual.
First year Java. Love it. Did methods today. Explained my views on defensive programming: "Always make sure that the sh*t falls on the other person's head". Explored this in terms of a method which adds an amount to the bar bill of a hotel customer when they pay for a drink:
boolean AddToBarBill ( int Amount ) {
// what do you put here to make sure that nobody can
// corrupt your bar bill...
}
Some nice problems: Consider the fact that a member of the bar staff and a guest might decide to attack your method and try and break it. If you let your users add negative numbers this means that naughty people could make their bill smaller. In an extreme case they could end up being paid for using the bar! So, stop them from adding negative numbers.
But then you have a problem with very big positive amounts. Because of the way that values are stored in computers a number can "wrap round" a bit like a car mileometer. So by adding carefully chosen positive values a naughty person could still make their bar bill smaller.
So, what you really do is ask the customer what the price range for drinks is, and then only allow prices amounts in this range to be added:
boolean AddToBarBill ( int Amount ) {
if ( ( Amount > MaxDrinkPrice ) ( Amount < MinDrinkPrice) )
{
return false;
}
else {
CustomerBill = CustomerBill + Amount;
return true;
}
}
This has two nice effects - it makes sure that your program always does the right thing and it makes it clear to the customer (i.e. the person who owns the hotel and is paying you to write the program) that it is their job to make sure that people in the bar enter the right prices - and that your program is doing the best it can to behave sensibly. The scary thing is that if you don't take these steps you may end up in court with your hotel customer (who has gone bankrupt) trying to take away all your money. It is interesting to see how a technical problem (stop someone from breaking my program) is really a specification problem (what do we mean by broken - and who has responsibility for breaking it).
0 Comments:
Post a Comment
<< Home