Chapter 5 : Programming By Contract

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 * location belong to maze * name.length() > 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. When to write method pre-conditions • i. Method needs to have object in a certain state. Client must know state of object. public void deleteFront(){…} public void add(Student s) {…} Chapter5

19. When to write method pre-conditions • ii. Method has parameters. Client must know expected parameter value. public int distanceTo(Date other){…} public void add(int x) {…} Chapter5

20. When to write method pre-conditions • iii. Method must follow a certain order in its execution. public String search(String pattern){…} public int totalPoints(){…} Chapter5

21. When to write method post-conditions • Always. Methods return values or change state of object. • For queries: Postcondition states what is computed. • For commands, client must know state of object after the invocation of the method. This state is described using the corresponding queries NOT private instance variables. public void insert(int x){…} Chapter5

22. 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

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

24. 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

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

26. 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

27. 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

28. Enumeration classes • In class TrafficSignal used constants to define a type with only a 3 int values: • TrafficSignal.GREEN • TrafficSignal.YELLOW • TrafficSignal.RED • In class PlayingCard used constants to define a type with four possible int values for suit, and thirteen values for rank. Chapter5

29. Enumeration classes • Using int values to encode user defined type values as in TrafficLight or PlayingCard provides not guarantee that user will use integers in the appropriate range. PlayingCard card = new PlayingCard(27, -4); • That is syntactically correct code but not legal values to create a card. Chapter5

30. Enumeration classes • Instead of using int values to encode user defined type values use enumeration classes. • Example: PlayingCard. • Inside this class define two enumeration classes: public enum Suit { clubs, diamonds, hearts, spades); public enum Rank { two, three, four, five, six, seven, eight, nine, ten, jack, queen, king, ace} • Class Suit consists of four objects named clubs, diamonds, hearts, spades. • Class Rank consists of 13 objects named two, three, four, … Chapter5

31. Enumeration classes • An enum declaration defines a public static, member class. • So, you can import the enum values using an static import statement. • In an enumeration class method toString() is define to return the name of the enum object as a String. PlayingCard.Suit.clubs.toString()  “clubs” Chapter5

32. 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

33. 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

34. 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

35. 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