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:

VectorGraphics project Visit http://www.rose- hulman.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)

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

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

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

Analyzing Quality of Class Design Cohesion Coupling [outline slide]

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

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

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

Quality Class Designs High cohesion Low coupling

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

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?

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

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

Documenting Side Effects /** * 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; } [[[Inserted to clear up muddiness from last time. Drop this slide if you fix session 13.]]]

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.

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.

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