1. Chapter 7 Designing Classes

2. Chapter Goals  To learn how to choose appropriate classes to implement  To understand the concepts of cohesion and coupling  To minimize the use of side effects  To document the responsibilities of methods and their callers with preconditions and postconditions  To understand the difference between instance methods and static methods

3.  To introduce the concept of static fields  To understand the scope rules for local variables and instance fields  To learn about packages

4. Choosing Classes  A class represents a single concept  Concepts from mathematics: Point Rectangle Ellipse  Concepts from real life BankAccount Purse  Actors (end in -er, -or) StringTokenizer Random (better called RandomNumberGenerator)  Utility classes--no objects, only static methods Math

5. Cohesion  Cohesive = public interface closely related to the single concept that the class represents  This class lacks cohesion: –public class Purse { public Purse(){...} public void addNickels(int count){...} public void addDimes(int count){...} public void addQuarters(int count){...} public double getTotal(){...} public static final double NICKEL_VALUE =0.05; public static final double DIME_VALUE =0.1; public static final double QUARTER_VALUE =0.25;... }

6. Cohesion  Two concepts: purse and coin  Solution: Make two classes: –public class Coin { public Coin(double aValue,String aName){...} public double getValue(){...} } public class Purse { public Purse(){...} public void add(Coin aCoin){...} public double getTotal(){...} }

7. Coupling  A class depends on another if it calls one of its methods  Purse depends on Coin because it calls getValue on coins  Coin does not depend on Purse  High Coupling = many class dependencies  Minimize coupling to minimize the impact of interface changes

8. Dependency Relationship between Purse and Coin Classes

9. High and Low Coupling between Classes

10. Accessor and Mutator Classes  Accessor: does not change the state of the implicit parameter (e.g. getBalance)  Mutator: changes the state of the implicit parameter (e.g. deposit )  Rule of thumb: Mutator should return void  Immutable class: all methods are accessors (e.g. String)

11. Side Effect Side Effect: any observable change outside the implicit parameter Example: modify explicit parameter public void transfer(double amount, BankAccount other) { balance = balance - amount; other.balance = other.balance + amount; }

12. Example: printing in method public void deposit(double amount) { if (amount < 0) System.out.println("Bad value");... } Reprehensible: couples with System, PrintStrea

13. Common Error: Can't Modify Primitive Type Parameters void transfer(double amount, double otherBalance) { balance = balance - amount; otherBalance = otherBalance + amount; } Won't work Scenario: double savingsBalance = 1000; harrysChecking.transfer(500, savingsBalance)

14. Modifying a Numeric Parameter has No Effect on Caller

15. Preconditions  Publish preconditions so the caller won't call methods with bad parameters /** Deposits money into this account. @param amount the amount of money to deposit (Precondition: amount >= 0) */  Typical use:  To restrict the parameters of a method  To require that a method is only called when the object is in an appropriate state  Method can do anything if called when precondition not fulfilled

16. Preconditions Method may throw exception if precondition violated if (amount < 0) throw new IllegalArgumentException(); balance = balance + amount; Nicer to throw exception than to silently muddle through if (amount < 0) return; // don't do this balance = balance + amount;

17. Method doesn't have to test for precondition. (Test may be costly) // no test--that's ok // if this makes the balance negative, // it's the caller's fault balance = balance + amount

18. Postconditions  Condition that's true after a method has completed. –/** Deposits money into this account. (Postcondition: getBalance() >= 0) @param amount the amount of money to deposit (Precondition: amount >= 0) */  Don't document trivial postconditions that repeat the @return clause  Contract: If caller fulfills precondition, method must fulfill postcondition

19. Static Methods  Every method must be in a class  Some methods have no implicit parameter  E.g. if all parameters are primitive class Numeric { public static boolean approxEqual(double x, double y) {... } }

20.  Call with class name instead of object: if (Numeric.approxEqual(a, b))...  main is static--there aren't any objects yet  Too many static methods are a sign of too little OO

21. Static Fields One field per class public class BankAccount {... private double balance; private int accountNumber; private static int lastAccountNumber; }

22. public BankAccount() { lastAssignedNumber++; // increment static field accountNumber = lastAssignedNumber; // set instance field } Minimize the use of static fields. (Static final fields are ok.)

23. A Static Field and Instance Fields

24. Scope  Scope of variable: region of program where you can refer to the variable by its name  Local variable scope: from definition to end of block  Class scope: all methods of the class  Must qualify public members outside scope, e.g. Math.sqrt

25.  Overlapping scope: local scope wins over class scope –public class Coin { public void draw(Graphics2D g2) { String name = "SansSerif"; // local scope g2.setFont(new Font(name,...)); // local name g2.drawString(this.name,...); // field name } private String name; // class scope... }

26. Packages

27. Placing Classes into Packages  To place classes in package, start file with package packagename; –package com.horstmann.bigjava; public class Numeric {... }  Default package has no name, no package statement

28. Importing Packages Can always use class without importing java.awt.Color backgroundColor = new java.awt.Color(...); Tedious to use fully qualified name Import lets you use shorter class name import java.awt.Color;... Color backgroundColor = new Color(...); Can import all classes in a package import java.awt.*; Never need to import java.lang

29. Package Names Package names should be unambiguous Recommendation: start with reversed domain name org.omg.CORBA com.horstmann.bigjava Path name should match package name com/horstmann/bigjava/Numeric.java Path name starts with class path export CLASSPATH=/home/walters:.

30. Base Directories and Subdirectories for Packages