1 / 27

Programming by Contract and Defensive Programming

Learn the concepts of programming by contract and defensive programming, understand the consequences of a client's lack of adherence to a contract, and the purpose and use of the assert statement.

naborsa
Download Presentation

Programming by Contract and Defensive Programming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related