An Introduction to Programming and Object Oriented Design using Java 2 nd Edition. May 2004 Jaime...

An Introduction to Programming and Object

Oriented Design using Java2nd Edition. May 2004

Jaime NiñoFrederick Hosch

Chapter 5 : Programming By Contract

2May 2004 Chapter5

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.

3May 2004 Chapter5

Method specifications

Client 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)

4May 2004 Chapter5

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)

5May 2004 Chapter5

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.

6May 2004 Chapter5

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.

7May 2004 Chapter5

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.

8May 2004 Chapter5

Programming by contract

Consequence: test for every possible error condition only once. Program efficiency.

Reduction of implementation complexity.

9May 2004 Chapter5

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)

10May 2004 Chapter5

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.

11May 2004 Chapter5

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.

Java’s assert statement can be used in verifying preconditions.

assert booleanExpression ;

12May 2004 Chapter5

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;

}

13May 2004 Chapter5

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;

}

14May 2004 Chapter5

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.

15May 2004 Chapter5

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?

16May 2004 Chapter5

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.

17May 2004 Chapter5

Pile complete specifications

public void remove (int number)Reduce the number of sticks by the specified amount.

require:number >= 0number <= this.sticks()

ensure:this.sticks() == old.sticks() -

number

18May 2004 Chapter5

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) {…}

19May 2004 Chapter5

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) {…}

20May 2004 Chapter5

When to write method pre-conditions

iii. Method must follow a certain order in its execution.

public String search(String pattern){…}

public int totalPoints(){…}

21May 2004 Chapter5

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){…}

22May 2004 Chapter5

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.

23May 2004 Chapter5

Query postconditions summary

Query postconditions say something about value returned.

24May 2004 Chapter5

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

25May 2004 Chapter5

Constructor postconditions summary

Constructor postconditions describe the initial state of the newly created object.

26May 2004 Chapter5

Preconditions, postconditions part of the specification

They should never mention private implementation components.

public void reset ()Reset the count to 0.

ensure:

count == 0 This is not correct! count is private.

27May 2004 Chapter5

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

28May 2004 Chapter5

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.

29May 2004 Chapter5

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.

30May 2004 Chapter5

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, …

31May 2004 Chapter5

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”

32May 2004 Chapter5

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.

33May 2004 Chapter5

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.

34May 2004 Chapter5

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.

35May 2004 Chapter5

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.