Programming by Contract and Defensive Programming

1. Chapter 5 : Programming By Contract

2. Objectives • After studying this chapter you should understand the following: • programming by contract, defensive programming, and difference between the two; • consequences of a client’s lack of adherence to a contract; • purpose and use of the assert statement. • Also, you should be able to: • express the responsibilities of client and server as a contract; • use assert statements to verify a client’s preconditions; • use contract to reason about a program’s behavior. Chapter5

3. Method specifications • Specification of Explorer’s constructor allows for any int value for strength and tolerance: • Client could give negative values. public Explorer (String name, Room location, int strength, int tolerance) Chapter5

4. Documenting requirements /** * Create a new Explorer with the specified name, * initial location, strength, and tolerance. * * @require strength >= 0 * tolerance >= 0 */ public Explorer (String name, Room location,int strength, int tolerance) Chapter5

5. Programming by contract • Programming style in which invocation of a method is viewed as a contract between client and server, with each having explicitly stated responsibilities. Chapter5

6. Programming by contract • Preconditions: requirements on client of a method. • Labeled “require” • Postconditions: requirements on server of a method. • labeled “ensure” • Preconditions and postconditions are part of the contract. Chapter5

7. Programming by contract • For method invocation to be correct: • client must make sure that preconditions are satisfied at time of call. • If preconditions are satisfied, server guarantees that postconditions will be satisfied when method completes otherwise server promises nothing at all. Chapter5

8. Programming by contract • Consequence: test for every possible error condition only once. • Program efficiency. • Reduction of implementation complexity. Chapter5

9. Programming by contract • Complete specification of Explorer’s constructor: /** * Create a new Explorer with the specified name, * initial location, strength, and tolerance. * * @require strength >= 0 * tolerance >= 0 * @ensure * this.name().equals(name) * this.location() == location * this.strength() == strength * this.tolerance() == tolerance */ public Explorer (String name, Room location,int strength, int tolerance) Chapter5

10. Implicit preconditions and postconditions • Implicit Preconditions: • Object arguments must be not null. • Type arguments imply a range of legal values. • Implicit postconditions: • Object result will be not null. • Type result implies a range of value of possible result. Chapter5

11. Verifying preconditions • Java’s assert statement can be used in verifying preconditions. • The boolean expression is evaluated • if true, statement has no effect. • If false, statement raises an error condition stopping execution of program displaying cause of error. assertbooleanExpression ; Chapter5

12. Verifying preconditions public Explorer (String name, Room location,int strength, int tolerance) { assert strength >= 0; assert tolerance >= 0; this.name = name; this.location = location; this.strength = strength; this.tolerance = tolerance; } Chapter5

13. Verifying preconditions (v.2) public Explorer (String name, Room location, int strength, int tolerance) { assert strength >= 0 :"precondition: strength ("+ strength + ") >= 0"; assert tolerance >= 0 : "precondition: tolerance (" + tolerance + ") >= 0"; this.name = name; this.location = location; this.strength = strength; this.tolerance = tolerance; } Chapter5

14. Pile specification • Pile instance models a pile of sticks from which players in turn removed 1, 2, or 3 sticks. • Command remove : public void remove (int number) • Reduce the number of sticks by the specified amount. Chapter5

15. Pile specification • Questions: • what if number is negative? Is legal? If so, what does this mean? • what if number is greater than the number of sticks remaining the pile? • what if number is not 1, 2, or 3? Chapter5

16. Pile specification • Not meaningful for a client to remove a negative number of sticks. • Removing more sticks than there are in pile also seems likely to be a client error. • Number of sticks than can legally be removed by a player is determined by rules of the game. • Not Pile’s responsibility. Chapter5

17. Pile complete specifications public void remove (int number) Reduce the number of sticks by the specified amount. require:number >= 0 number <= this.sticks() ensure: this.sticks() == old.sticks() - number Chapter5

18. Preconditions summary • Preconditions must be satisfied by client when invoking method. • Occasionally, preconditions constrain order in which methods can be invoked or require that an object be in a certain state before invocation. • It might be necessary that a door be unlocked before it can be opened, or that an automobile be started before it can be moved. • Most often preconditions constrain values that client can provide as arguments when invoking method. • Remember: if an argument is not constrained by a precondition, method must be prepared to accept any value of the specified type. Chapter5

19. Query postconditions summary • Query postconditions say something about value returned. Chapter5

20. Command postconditions summary • Commands result in a change of state. • Command postconditions describe new state of the object after execution of command. • New state is often compared to the previous state, the state of the object before command was invoked. • We use “old” to refer to state before call Chapter5

21. Constructor postconditions summary • Constructor postconditions describe the initial state of the newly created object. Chapter5

22. Preconditions, postconditions part of the specification • They should never mention private implementation components. • publicvoid reset () • Reset the count to 0. • ensure:count == 0This is not correct! count is private. Chapter5

23. Preconditions, postconditions part of the specification • The method currentCount is part of the public specification of the class. • publicvoid reset () • Reset the count to 0. • ensure:this.currentCount() == 0 Chapter5

24. Summary • Introduced a programming style called programming by contract. • Basic idea is to make explicit responsibilities of client and server in a method invocation. • Invocation of a server method by client is viewed as a contract between the client and the server. • Server promises to perform action specified by method and to ensure that method’s postconditions are satisfied, but only if • Client meets the preconditions. Chapter5

25. Summary • Preconditions are client’s responsibility; • Postconditions are the server’s. • If the client fails to meet the preconditions, the contract is void: the server is not obligated to behave in any specific way. Chapter5

26. Summary • Preconditions can be verified using Java’s assert statement. • If the boolean expression in the assert statement is true, the statement has no effect. • If it is false, an error exception occurs and the program terminates. Chapter5

27. Summary • Preconditions constrain values a client can provide as argument. • Postconditions for a query generally say something about the value returned. • Postconditions for a command describe state of the object after command is completed in terms of state before the command was begun. Chapter5