Class DesignClass Design

CSC 171 FALL 2004

LECTURE 11

READINGREADING

Read Chapter 7It’s abstractBut it should help with project #1

Design MethodologyDesign Methodology

1. Problem Definition

2. Requirements Analysis

3. Architecture

4. Construction

5. Testing

6. Future Improvements

Software LifecycleSoftware Lifecycle

Classes and ObjectsClasses and ObjectsObject 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 How do we choose a class to implement?implement?

A single concept

A “real world” thing– Student, car, monster

An actor– StringTokenizer : “one who does”

A utility– The “math” class.

CohesionCohesion

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

IncohesiveIncohesive

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

CouplingCoupling

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 PurseHigh Coupling = many class dependencies Minimize coupling to minimize the impact

of interface changes

Coupling & DependencyCoupling & Dependency

Design ExerciseDesign ExerciseConsider the following JAVA applicationWhat would make good “classes”

Accessor and Mutator ClassesAccessor 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 voidImmutable class: all methods are accessors

(e.g. String)

Side EffectsSide 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");   . . .}

PreconditionsPreconditions

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

PreconditionsPreconditions

Method may throw exception if precondition violated

if (amount < 0)throw new IllegalArgumentException();

balance = balance + amount;

PostconditionsPostconditions

Condition that's true after a method has completed.

Contract: If caller fulfills precondition, method must fulfill postcondition

Static MethodsStatic 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 FieldsStatic 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 fieldaccountNumber = lastAssignedNumber; // set instance field}