1. An Introduction to Programming and Object Oriented Design using Java 2 nd Edition. May 2004 Jaime Niño Frederick Hosch Chapter 5 : Programming By Contract

2. 1May 2004Chapter5 Objectives zAfter studying this chapter you should understand the following: yprogramming by contract, defensive programming, and difference between the two; yconsequences of a clients lack of adherence to a contract; ypurpose and use of the assert statement. zAlso, you should be able to: yexpress the responsibilities of client and server as a contract; yuse assert statements to verify a clients preconditions; yuse contract to reason about a programs behavior.

3. 2May 2004Chapter5 Method specifications zClient could give negative values. Specification of Explorers constructor allows for any int value for strength and tolerance: public Explorer (String name, Room location, int strength, int tolerance)

4. 3May 2004Chapter5 Documenting requirements /** * Create a new Explorer with the specified name, * initial location, strength, and tolerance. * * @requirestrength >= 0 * tolerance >= 0 * location belong to maze * name.length() > 0 */ public Explorer (String name, Room location, int strength, int tolerance)

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

6. 5May 2004Chapter5 Programming by contract zPreconditions: requirements on client of a method. yLabeled require z Postconditions: requirements on server of a method. ylabeled ensure zPreconditions and postconditions are part of the contract.

7. 6May 2004Chapter5 Programming by contract zFor method invocation to be correct: yclient must make sure that preconditions are satisfied at time of call. yIf preconditions are satisfied, server guarantees that postconditions will be satisfied when method completes otherwise server promises nothing at all.

8. 7May 2004Chapter5 Programming by contract zConsequence: test for every possible error condition only once. yProgram efficiency. yReduction of implementation complexity.

9. 8May 2004Chapter5 Programming by contract zComplete specification of Explorers constructor: /** * Create a new Explorer with the specified name, * initial location, strength, and tolerance. * * @requirestrength >= 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)

10. 9May 2004Chapter5 Implicit preconditions and postconditions zImplicit Preconditions: yObject arguments must be not null. yType arguments imply a range of legal values. zImplicit postconditions: yObject result will be not null. yType result implies a range of value of possible result.

11. 10May 2004Chapter5 Verifying preconditions zThe boolean expression is evaluated yif true, statement has no effect. yIf false, statement raises an error condition stopping execution of program displaying cause of error. Javas assert statement can be used in verifying preconditions. assert booleanExpression ;

12. 11May 2004Chapter5 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; }

13. 12May 2004Chapter5 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; }

14. 13May 2004Chapter5 Pile specification zPile 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.

15. 14May 2004Chapter5 Pile specification zQuestions: 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?

16. 15May 2004Chapter5 Pile specification zNot meaningful for a client to remove a negative number of sticks. zRemoving more sticks than there are in pile also seems likely to be a client error. zNumber of sticks than can legally be removed by a player is determined by rules of the game. zNot Piles responsibility.

17. 16May 2004Chapter5 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

18. 17May 2004Chapter5 When to write method pre-conditions zi. Method needs to have object in a certain state. Client must know state of object. public void deleteFront(){…} public void add(Student s) {…}

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

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

21. 20May 2004Chapter5 When to write method post-conditions zAlways. Methods return values or change state of object. zFor queries: Postcondition states what is computed. zFor 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){…}

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

23. 22May 2004Chapter5 Query postconditions summary zQuery postconditions say something about value returned.

24. 23May 2004Chapter5 Command postconditions summary zCommands result in a change of state. zCommand postconditions describe new state of the object after execution of command. zNew 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

25. 24May 2004Chapter5 Constructor postconditions summary zConstructor postconditions describe the initial state of the newly created object.

26. 25May 2004Chapter5 Preconditions, postconditions part of the specification zThey should never mention private implementation components. public void reset () Reset the count to 0. ensure: count == 0 This is not correct! count is private.

27. 26May 2004Chapter5 Preconditions, postconditions part of the specification The method currentCount is part of the public specification of the class. public void reset () Reset the count to 0. ensure: this.currentCount() == 0

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

29. 28May 2004Chapter5 Enumeration classes zUsing 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); zThat is syntactically correct code but not legal values to create a card.

30. 29May 2004Chapter5 Enumeration classes zInstead of using int values to encode user defined type values use enumeration classes. zExample: PlayingCard. yInside 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, …

31. 30May 2004Chapter5 Enumeration classes zAn enum declaration defines a public static, member class. ySo, you can import the enum values using an static import statement. zIn an enumeration class method toString() is define to return the name of the enum object as a String. PlayingCard.Suit.clubs.toString() clubs

32. 31May 2004Chapter5 Summary zIntroduced a programming style called programming by contract. zBasic idea is to make explicit responsibilities of client and server in a method invocation. zInvocation of a server method by client is viewed as a contract between the client and the server. yServer promises to perform action specified by method and to ensure that methods postconditions are satisfied, but only if yClient meets the preconditions.

33. 32May 2004Chapter5 Summary zPreconditions are clients responsibility; zPostconditions are the servers. zIf the client fails to meet the preconditions, the contract is void: the server is not obligated to behave in any specific way.

34. 33May 2004Chapter5 Summary zPreconditions can be verified using Javas assert statement. yIf the boolean expression in the assert statement is true, the statement has no effect. yIf it is false, an error exception occurs and the program terminates.

35. 34May 2004Chapter5 Summary zPreconditions constrain values a client can provide as argument. zPostconditions for a query generally say something about the value returned. zPostconditions for a command describe state of the object after command is completed in terms of state before the command was begun.