copyright by Scott GrissomCh 7 Designing Classes Slide 1 Well Designed Classes (Ch 7) Applications are a collection of interacting classes Our Goal It works correctly Additional Goals Easy to read Easy to reuse Easy to maintain Easy to extend Also known as “elegant code”

copyright by Scott GrissomCh 7 Designing Classes Slide 2 Cohesion (7.11) the number of operations or tasks contained in a single entity Methods should do one, and only one, task This makes them short Easy to understand Easier to reuse Classes model well defined single entities Avoid low cohesion Strive for high cohesion

copyright by Scott GrissomCh 7 Designing Classes Slide 3 Coupling (7.6) the interconnectedness of classes classes should be independent and not rely too heavily on other classes Changes to code in one class should have minimal impact on other classes Avoid tight coupling Strive for loose coupling

copyright by Scott GrissomCh 7 Designing Classes Slide 4 World of Zuul Start with a demo Game Room Parser Command CommandWords Provide students with the code for Game and Room

copyright by Scott GrissomCh 7 Designing Classes Slide 5 Avoid code duplication (7.4) Place duplicate code into a method Notice the duplicate code in Game class This is low cohesion create a new method to handle the code (high cohesion) printLocationInfo() page 197

copyright by Scott GrissomCh 7 Designing Classes Slide 6 Decouple Code (7.5) Game knows too much about Room Improve Room class make instance variables private create getExit(direction) method nextRoom = currentRoom.getExit(“north”); Modify Game class update createRooms() update printWelcome() update goRoom() Room and Game are too tightly coupled

copyright by Scott GrissomCh 7 Designing Classes Slide 7 Extending the design (7.5) What if we want additional directions such as UP and DOWN? How much code do we have to change? add hashmap to Room to allow for an unlimited number of directions update setExits()

copyright by Scott GrissomCh 7 Designing Classes Slide 8 Responsibility Driven Design 7.7 Room should be responsible for generating the exit String, not Game String getExitString() update getLongDescription() update the Game class

copyright by Scott GrissomCh 7 Designing Classes Slide 9 More Low Cohesion (7.10) Who should list the commands in help? Probably Parser. String getCommandList() Good design tip: strive to have all printing to the screen occur in one class

copyright by Scott GrissomCh 7 Designing Classes Slide 10 More Zuul Project 7.11 discusses an Item class 7.12 discusses a Player class 7.13 should be skipped

copyright by Scott GrissomCh 7 Designing Classes Slide 11 Class methods (7.15) static methods are associated with a class and not an instance Math.sqrt() public static void main(String [] args){ Game g = new Game(); g.play(); }