1 / 17

Understanding Preconditions and Postconditions in Object-Oriented Programming

Learn about preconditions, postconditions, static methods, fields, scope, and packages in object-oriented programming. Understand their importance and implementation for writing efficient and reliable code. Reference: Big Java 3rd Edition by Cay Horstmann.

angieg
Download Presentation

Understanding Preconditions and Postconditions in Object-Oriented 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. Week 13 Introduction to Computer Science and Object-Oriented Programming COMP 111 George Basham

  2. Week 13 Topics 13.1.1 Preconditions and Postconditions 13.1.2 Static Methods 13.1.3 Static Fields 13.1.4 Scope 13.1.5 Packages

  3. 13.1.1 Preconditions and Postconditions • A precondition is a requirement that the caller of a method must meet for the method to execute properly • If a method is called in violation of a precondition, the method is not responsible for computing the correct result

  4. 13.1.1 Preconditions and Postconditions Cont. public void deposit (double amount) { if (amount < 0) throw new IllegalArguementException (“Amount is less than zero”); balance = balance + amount; }

  5. 13.1.1 Preconditions and Postconditions Cont. • A postcondition is a guarantee made by the method to its caller about a return value or the final state of an object after the execution of the method • Postconditions are enforced by good testing practices

  6. 13.1.1 Preconditions and Postconditions Cont. public void testDeposit () { BankAccount b = new BankAccount(100.00); b.deposit(50.00); assertEquals(150.00, b.getDeposit(), .0001); }

  7. 13.1.2 Static Methods • A method that is called on a class rather than an object is called a static method or a class method • A classic example is the Math class, which is a utility class that has only static methods and static instance fields • double d = Math.sqrt(33.33); • double d = Financial.percentOf(5.5, 7.00);

  8. 13.1.2 Static Methods Cont. public class Financial () { publicstaticdouble percentOf (double p, double a) { return (p / 100) * a; } // More financial methods can be added here. }

  9. 13.1.3 Static Fields • A static field belongs to the class, not to any object of the class • All instances of an object “share” the static variable – it belongs to the class, not to each instance of the class • public static final double PI = 3.14159265358979323846;

  10. 13.1.3 Static Fields Cont. public class BankAccount () { private static int lastAcctNbr = 1000; public BankAccount() { lastAcctNbr++; accountNumber = lastAcctNbr; } . . . }

  11. 13.1.4 Scope • The scope of a variable is the region of a program in which the variable can be accessed • The scope of a local variable cannot contain the definition of another variable with the same name

  12. 13.1.4 Scope Cont. • A qualified name is prefixed by it class name or by an object reference, such as Math.sqrt or harrysChecking.getBalance() • An unqualified instance field or method refers to the this parameter • A local variable can shadow an instance field with the same name (the local variable “wins out”). Use this to access the shadowed instance field.

  13. 13.1.5 Packages • A package is a set of related classes • The Java library consists of dozens of packages • To put classes in a package, you must put package packageName; as the first instruction in the source file containing the classes

  14. 13.1.5 Packages Cont. • The import directive lets you refer to a class of a package by its class name, without the package prefix • java.util.Scanner in = new java.util.Scanner(System.in); • import java.util.Scanner; • Now you don’t have to fully qualify by package

  15. 13.1.5 Packages Cont. • You can import all class of a package with an import statement that ends in .* • import java.util.*; • Another reason for packages is to avoid name clashes • java.util.Timer versus javax.swing.Timer

  16. 13.1.5 Packages Cont. • If you write your own packages, you need to study concepts of how package names and the underlying directory structure that the packages are stored in work • You will also need to understand how packages work with your operating system CLASSPATH

  17. Reference: Big Java 3rd Edition by Cay Horstmann 13.1.1 Preconditions and Postconditions (section 8.5 in Big Java) 13.1.2 Static Methods (section 8.6 in Big Java) 13.1.3 Static Fields (section 8.7 in Big Java) 13.1.4 Scope (section 8.8 in Big Java) 13.1.5 Packages (section 8.9 in Big Java)

More Related