Class Design CSC 171 FALL 2004 LECTURE 11

READING Read Chapter 7 It’s abstract But it should help with project #1

Design Methodology 1. Problem Definition 2. Requirements Analysis 3. Architecture 4. Construction 5. Testing 6. Future Improvements

Software Lifecycle

Classes and Objects Object oriented programs – Define classes of objects – Make specific object out of class definitions – Run by having the objects interact A class is a type of thing – Instructor An object is a specific thing – Ted An object is an instance of a class

How do we choose a class to implement? A single concept A “real world” thing – Student, car, monster An actor – StringTokenizer : “one who does” A utility – The “math” class.

Cohesion A “cohesive” class has a public interface closely related to the single concept that the class represents

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

Cohesive Concepts 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(){...}... }

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

Coupling & Dependency

Design Exercise Consider the following JAVA application What would make good “classes”

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)

Side Effects Side Effect: any observable change outside the implicit parameter Example: printing in method public void deposit(double amount){ if (amount < 0) System.out.println("Bad value");... }

Preconditions Document the parameters of a method 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

Preconditions Method may throw exception if precondition violated if (amount < 0) throw new IllegalArgumentException(); balance = balance + amount;

Postconditions Condition that's true after a method has completed. Contract: If caller fulfills precondition, method must fulfill postcondition

Static Methods Every method must be in a class E.g. if all parameters are primitive class Numeric { public static boolean approxEqual(double x, double y) {...} } 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

Static Fields “Class variables” One field per class Minimize the use of static fields. Static final fields are ok. “class constants”

public class BankAccount {... private double balance; private int accountNumber; private static int lastAccountNumber; }

public BankAccount() { lastAssignedNumber++; // increment static field accountNumber = lastAssignedNumber; // set instance field }