1. CSSE 220 Day 17 Introduction to your Vector Graphics project
SwingDemo continued
Designing classes
Screen Layout sketch for VG
Bring :
Handout for Pair Programming
In-class Quizzes
(No in-class quiz today)
These Slides
Schedule for today
Attendance PIN:

2. VectorGraphics project
Visit
hulman.edu/class/csse/csse220/current/Projects/VectorGraphics/teams.html
And find your teammates. Sit with them.
Introduce yourselves:

3. 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)

4. What is good object-oriented design?
It starts with good classes…

5. Good Classes Typically
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
Discuss why the ‘er’s are highlighted for actors: actors == do-ers Q2

6. What Stinks? Bad Class Smells
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

7. Analyzing Quality of Class Design
Cohesion
Coupling
[outline slide]

8. Cohesion A class should represent a single concept
Public methods and constants should be cohesive
Which is more cohesive?
CashRegister
double NICKEL_VALUE
double DIME_VALUE
double QUARTER_VALUE
void add(int nickels, int dimes, int quarters) …
CashRegister
void add(ArrayList<Coin> coins) …
Coin
double getValue() Q4

9. Dependency Relationship
When one classes requires another class to do its job, the first class depends on the second
Shown on UML diagrams as:
dashed line
with open arrowhead
CashRegister
void add(ArrayList<Coin> coins) …
Note CashRegister depends on Coin
But Coin does NOT depend on CashRegister
Coin
double getValue() Q5

10. Coupling Lots of dependencies == high coupling
Few dependencies == low coupling
Which is better? Why?
Low coupling  less brittle, can change one class without changing the others; can reason about one class without thinking about many others. Q6

11. Quality Class Designs
High cohesion
Low coupling

12. Accessors and Mutators Review
Accessor method: accesses information without changing any
Mutator method: modifies the object on which it is invoked
[Ask for examples of each that we’ve used] Q7

13. Immutable Classes Accessor methods are very predictable
Easy to reason about!
Immutable classes:
Have only accessor methods
No mutators
Examples: String, Double
Is Rectangle immutable?

14. Immutable Class Benefits
Easier to reason about, less to go wrong
Can pass around instances “fearlessly”
A: Don’t have to worry about some other code changing “our” object. Q8

15. Avoid this if you can! Document it if you can’t
Side Effects
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; }
What are the side effects in the code snippet?
Why would we want to avoid side effects on other parameters?
(surprising to the caller. Be sure to document well.)
Avoid this if you can! Document it if you can’t

16. Documenting Side Effects
/**
* Transfers the given amount from this
* account to the other account. Mutates
* this account and other. *
amt
* amount to be transferred
other
* receiving account (mutated) */
public void transfer(double amt, Account other) {
this.balance -= amt;
other.balance += amt; }
[[[Inserted to clear up muddiness from last time. Drop this slide if you fix session 13.]]]

17. Class Design Exercise
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.

18. Class design exercise
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.

19. Vector Graphics Show movie See features in instructions
Make a Screen Layout sketch, per instructions