Class Design

1
Class Design

• CSC 171 FALL 2004
• LECTURE 11

2
READING

• Read Chapter 7
• Its abstract
• But it should help with project 1

3
Design Methodology

• Problem Definition
• Requirements Analysis
• Architecture
• Construction
• Testing
• Future Improvements

4
Software Lifecycle
5
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

6
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.

7
Cohesion

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

8
Incohesive

• public class Pursepublic 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 ...

9
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()... ...
  

10
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

11
Coupling Dependency
12
(No Transcript)
13
Design Exercise

• Consider the following JAVA application
• What would make good classes

14
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)

15
Side Effects

• Side Effect any observable change outside the
  implicit parameter
• Example printing in method
• public void deposit(double amount)    if
  (amount lt 0)    System.out.println("Bad
  value")   . . .

16
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

17
Preconditions

• Method may throw exception if precondition
  violated
• if (amount lt 0)throw new IllegalArgumentException
  ()
• balance balance amount

18
Postconditions

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

19
Static Methods

• Every method must be in a class
• E.g. if all parameters are primitiveclass
  Numeric  
• public static boolean        
  approxEqual(double x, double y)   . . .
• Call with class name instead of objectif
  (Numeric.approxEqual(a, b)) . . .
• main is static--there aren't any objects yet
• Too many static methods are a sign of too little
  OO

20
Static Fields

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

21

• public class BankAccount. . .private double
  balanceprivate int accountNumberprivate
  static int lastAccountNumber

22

• public BankAccount()lastAssignedNumber //
  increment static fieldaccountNumber
  lastAssignedNumber // set instance field