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

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 client’s 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 client’s preconditions; yuse contract to reason about a program’s behavior.

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

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

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.

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.

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.

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

8May 2004Chapter5 Programming by contract zComplete specification of Explorer’s constructor: /** * Create a new Explorer with the specified name, * initial location, strength, and tolerance. * >= 0 * tolerance >= 0 *this.name().equals(name) * this.location() == location * this.strength() == strength * this.tolerance() == tolerance */ public Explorer (String name, Room location, int strength, int tolerance)

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.

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.  Java’s assert statement can be used in verifying preconditions. assert booleanExpression ;

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; }

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; }

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.

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?

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 Pile’s responsibility.

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

17May 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.

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

19May 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

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

21May 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.

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

23May 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 method’s postconditions are satisfied, but only if yClient meets the preconditions.

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

25May 2004Chapter5 Summary zPreconditions can be verified using Java’s 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.

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