Introduction to your Vector Graphics project
SwingDemo continued
Designing classes
Screen Layout sketch for VG

Visit
http://www.rosehulman.edu/class/csse/csse220/current/Projects/VectorGraphics/teams.html
And find your teammates. Sit with them.
Introduce yourselves:

With your teammates, continue your
SwingDemo project, helping everyone reach
the same point in the project (pair program,
with the teammates furthest along being the
observer)
It starts with good classes…


Often come from nouns in the problem
description
May…
◦ Represent single concepts
 Circle, Investment
◦ Be abstractions of real-life entities
 BankAccount, TicTacToeBoard
◦ Be actors
 Scanner, CircleViewer
◦ Be utilities
 Math
Q2

Can’t tell what it does from its name
◦ PayCheckProgram

Turning a single action into a class
◦ ComputePaycheck

Name isn’t a noun
◦ Interpolate, Spend
Q3

Cohesion

Coupling



A class should represent a single concept
Public methods and constants should be
cohesive
Which is more cohesive?
CashRegister
CashRegister
double NICKEL_VALUE
double DIME_VALUE
double QUARTER_VALUE
void add(ArrayList<Coin> coins)
…
void add(int nickels, int
dimes, int quarters)
…
Coin
double getValue()
Q4

When one classes requires another class to
do its job, the first class depends on the
second
CashRegister

Shown on UML
diagrams as:
void add(ArrayList<Coin> coins)
…
◦ dashed line
◦ with open arrowhead
Coin
double getValue()
Q5

Lots of dependencies == high coupling
Few dependencies == low coupling

Which is better? Why?

Q6

High cohesion

Low coupling


Accessor method: accesses information
without changing any
Mutator method: modifies the object on
which it is invoked
Q7

Accessor methods are very predictable
◦ Easy to reason about!

Immutable classes:
◦ Have only accessor methods
◦ No mutators

Examples: String, Double

Is Rectangle immutable?

Easier to reason about, less to go wrong

Can pass around instances “fearlessly”
Q8


Side effect: any modification of data
Method side effect: any modification of data
visible outside the method
◦ Mutator methods: side effect on implicit parameter
◦ Can also have side effects on other parameters:
 public void transfer(double amt, Account other)
{
this.balance -= amt;
other.balance += amt;
}
Avoid this if you can! Document it if you can’t
/**
* Transfers the given amount from this
* account to the other account. Mutates
* this account and other.
*
* @param amt
*
amount to be transferred
* @param other
*
receiving account (mutated)
*
*/
public void transfer(double amt, Account other) {
this.balance -= amt;
other.balance += amt;
}


Suppose you were going to implement a
program to let two people play chess against
each other. Think about what classes you
would need. (Search on-line to find the rules
of chess if you aren’t familiar with the game.)
List all the classes that you can think of that
might be useful in implementing your
program. For now you can assume that users
will enter moves in the console, but you’ll
display the board in a graphics window.
◦ From your list of potential classes, decide which
ones you would use in an actual implementation.
Pay particular attention to the rules for good
classes that we discussed in class. Sketch a UML
class diagram for these classes. Show the public
interface (including the arguments of the methods)
of each class and the dependency relationships
between the classes. Recall that dependency
relationships are indicated by dashed lines with
open arrow heads.
◦ Write a couple of paragraphs explaining why you
chose the classes that you did for your design.
Discuss the cohesion and coupling of your classes.



Show movie
See features in instructions
Make a Screen Layout sketch, per instructions