1 / 19

CSSE 220 Day 17

CSSE 220 Day 17. Introduction to your Vector Graphics project SwingDemo continued Designing classes Screen Layout sketch for VG. VectorGraphics project. Visit http://www.rose-hulman.edu/class/csse/csse220/current/Projects/VectorGraphics/teams.html

mead
Download Presentation

CSSE 220 Day 17

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CSSE 220 Day 17 Introduction to your Vector Graphics project SwingDemo continued Designing classes Screen Layout sketch for VG

  2. 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:

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

  8. Cohesion • 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

  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) … Coin double getValue() Q5

  10. Coupling • Lots of dependencies == high coupling • Few dependencies == low coupling • Which is better? Why? 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 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” Q8

  15. 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;} 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. * * @param amt * amount to be transferred * @param other * receiving account (mutated) * */ public void transfer(double amt, Account other) { this.balance -= amt; other.balance += amt; }

  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

More Related