1. CS 151: Object-Oriented Design August 22 Class Meeting Department of Computer Science San Jose State University Fall 2013 Instructor: Ron Mak www.cs.sjsu.edu/~mak

2. SJSU Dept. of Computer Science Fall 2013: August 22 CS 151: Object-Oriented Design © R. Mak 2 Goals of the Course  Become better programmers. Develop well-designed software applications that do what they're supposed to do...... and are flexible, reliable, and maintainable. Use proven object-oriented techniques.  Learn important job skills that employers want. Work as a member of a small programming team. Gain experience on how to cooperate and coordinate your joint efforts to design, develop, and test applications. Employ modern industry-standard software engineering practices. _

3. SJSU Dept. of Computer Science Fall 2013: August 22 CS 151: Object-Oriented Design © R. Mak 3 Course Notes  Class website http://www.cs.sjsu.edu/~mak/ Green sheet Lecture notes and handouts Assignments  Required textbook: Object-Oriented Design & Patterns, 2 nd edition by Cay Horstmann _

4. SJSU Dept. of Computer Science Fall 2013: August 22 CS 151: Object-Oriented Design © R. Mak 4 Course Overview  First half Journey to good design Object-oriented design process Guidelines for class design Interface types and polymorphism  Midterm  Second half Patterns and GUI programming Inheritance and abstract classes The Java object model Frameworks Multithreaded programming  Final There will be quizzes during some classes.

5. SJSU Dept. of Computer Science Fall 2013: August 22 CS 151: Object-Oriented Design © R. Mak 5 Small Project Teams  Assignments will be done by small project teams. Each team will turn in one set of work for each assignment. Each team member will get the same score for the assignment. Each team is responsible for choosing a team lead and dividing up the work among the team members.  Form your own teams of 3 or 4 students each. Choose your team members wisely!  Be sure you’ll be able to meet and communicate with each other and work together well.  No moving to another team. E-mail me your team name and the list of team members and email addresses by Thursday, August 29: ron.mak@sjsu.edu _ron.mak@sjsu.edu

6. SJSU Dept. of Computer Science Fall 2013: August 22 CS 151: Object-Oriented Design © R. Mak 6 Individual Responsibilities You are personally responsible for participating and contributing to your team’s work, and for understanding each part of the work for every assignment, whether or not you worked on that part.

7. SJSU Dept. of Computer Science Fall 2013: August 22 CS 151: Object-Oriented Design © R. Mak 7 Postmortem Assessment Report  At the end of the semester, each student will individually turn in a short (1 or 2 pp.) report: A brief description of what you learned in the course.  An assessment of your personal accomplishments for your project team. An assessment of each of your project team members. _

8. SJSU Dept. of Computer Science Fall 2013: August 22 CS 151: Object-Oriented Design © R. Mak 8 Individual Student’s Overall Class Grade  50% assignments (team scores)  15% quizzes (individual scores)  15% midterm exam (individual score)  20% final exam (individual score)  Final letter grade based on the class curve.  Participation will be important! Can move your final grade up or down, especially in borderline cases. Participation in class Participation in your team  As reported by the postmortem assessment reports. _

9. SJSU Dept. of Computer Science Fall 2013: August 22 CS 151: Object-Oriented Design © R. Mak 9 Take roll!

10. SJSU Dept. of Computer Science Fall 2013: August 22 CS 151: Object-Oriented Design © R. Mak 10 It’s Not Just Object-Oriented Design  The full title of the course really ought to be Object-Oriented Analysis and Design (OOAD) We’ll see later what we mean by analysis. Do we know what we mean by design?  architecture  appearance  functionality  how something is built  good vs. bad? _

11. SJSU Dept. of Computer Science Fall 2013: August 22 CS 151: Object-Oriented Design © R. Mak 11 What Makes a Software Application Good?  It does what it’s supposed to do.  It’s well-designed. reliable robust flexible object-oriented architecture? uses design patterns?  It’s easy to modify and maintain. Things are always changing! _

12. SJSU Dept. of Computer Science Fall 2013: August 22 CS 151: Object-Oriented Design © R. Mak 12 How Do You Achieve “Good Design”?  Sorry, there is no magic formula. Learning lots of object-oriented tools and techniques alone won’t give you good design. Just using design patterns won’t give you good design. For a nontrivial application, good design won’t simply “happen”.  Good design is a destination reached after a journey. Every programmer must take this trip for every application. The journey can be longer for less-experienced programmers.  false starts  meandering  wrong paths  backtracking _

13. SJSU Dept. of Computer Science Fall 2013: August 22 CS 151: Object-Oriented Design © R. Mak 13 It’s an Iterative Process  Achieving good design is an iterative process. As you’re developing the application, you will revisit your design several times. Even the very best programmers can’t come up with the perfect good design the first time every time. The journey to good design requires that you make corrections, refinements, and other improvements along the way.  The journeys will become shorter as you become more experienced. Practice, practice, practice. Learn object-oriented tools and techniques. Learn when to use design patterns. More practice, practice, practice. _

14. SJSU Dept. of Computer Science Fall 2013: August 22 CS 151: Object-Oriented Design © R. Mak 14 A Poor Design is Not Necessarily a Failure... ... if it soon leads to a better design. Don’t paralyze yourself trying to come up with a perfect design right from the start.  Goal: Recognize a poor design early during development and start to improve it iteratively as soon as possible.  Even better: Try not to start with a really bad design. You will learn quickly how not to do a bad design! _

15. SJSU Dept. of Computer Science Fall 2013: August 22 CS 151: Object-Oriented Design © R. Mak 15 Example: Rick’s Guitars  Inventory Management Application for Rick’s Guitars Maintain a guitar inventory. Locate guitars for customers. UML class diagrams From: Head First Object-Oriented Analysis & Design, O’Reilly, 2006.

16. SJSU Dept. of Computer Science Fall 2013: August 22 CS 151: Object-Oriented Design © R. Mak 16 public class Guitar { private String serialNumber, builder, model, type, backWood, topWood; private double price; public Guitar(String serialNumber, double price, String builder, String model, String type, String backWood, String topWood) { this.serialNumber = serialNumber; this.price = price; this.builder = builder; this.model = model; this.type = type; this.backWood = backWood; this.topWood = topWood; }... The Guitar Class Why private?

17. SJSU Dept. of Computer Science Fall 2013: August 22 CS 151: Object-Oriented Design © R. Mak 17... public String getSerialNumber() {return serialNumber;} public double getPrice() {return price;} public void setPrice(float newPrice) { this.price = newPrice; } public String getBuilder() {return builder;} public String getModel() {return model;} public String getType() {return type;} public String getBackWood() {return backWood;} public String getTopWood() {return topWood;} } The Guitar Class, cont’d

18. SJSU Dept. of Computer Science Fall 2013: August 22 CS 151: Object-Oriented Design © R. Mak 18 The Inventory Class public class Inventory { private List guitars; public Inventory() { guitars = new LinkedList(); } public void addGuitar(String serialNumber, double price, String builder, String model, String type, String backWood, String topWood) { Guitar guitar = new Guitar(serialNumber, price, builder, model, type, backWood, topWood); guitars.add(guitar); }... }

19. SJSU Dept. of Computer Science Fall 2013: August 22 CS 151: Object-Oriented Design © R. Mak 19 The Inventory Class, cont’d public Guitar getGuitar(String serialNumber) { for (Iterator iter = guitars.iterator(); iter.hasNext(); ) { Guitar guitar = (Guitar) iter.next(); if (guitar.getSerialNumber().equals(serialNumber)) { return guitar; } return null; }

20. SJSU Dept. of Computer Science Fall 2013: August 22 CS 151: Object-Oriented Design © R. Mak 20 The Inventory Class, cont’d public Guitar search(Guitar searchGuitar) { for (Iterator iter = guitars.iterator(); iter.hasNext(); ) { Guitar guitar = (Guitar) iter.next(); String builder = searchGuitar.getBuilder(); if ((builder != null) && (!builder.equals("")) && (!builder.equals(guitar.getBuilder()))) continue; String model = searchGuitar.getModel(); if ((model != null) && (!model.equals("")) && (!model.equals(guitar.getModel()))) continue; String type = searchGuitar.getType(); if ((type != null) && (!searchGuitar.equals("")) && (!type.equals(guitar.getType()))) continue; String backWood = searchGuitar.getBackWood(); if ((backWood != null) && (!backWood.equals("")) && (!backWood.equals(guitar.getBackWood()))) continue; String topWood = searchGuitar.getTopWood(); if ((topWood != null) && (!topWood.equals("")) && (!topWood.equals(guitar.getTopWood()))) continue; return guitar; } return null; }

21. SJSU Dept. of Computer Science Fall 2013: August 22 CS 151: Object-Oriented Design © R. Mak 21 Problems!  Case-sensitive string comparisons. Make them case insensitive.  Badly used string fields. Replace them with enumerated types.  Assumes at most only one guitar match. Return a list of matching guitars. _

22. SJSU Dept. of Computer Science Fall 2013: August 22 CS 151: Object-Oriented Design © R. Mak 22 Iteration #1: Remove String Fields public class Guitar { private String serialNumber, model; private double price; private Builder builder; private Type type; private Wood backWood, topWood; … public enum Type { ACOUSTIC("acoustic"), ELECTRIC("electric"), UNSPECIFIED("unspecified"); String value; private Type(String value) {this.value = value;} public String toString() {return value;} } Why private?

23. SJSU Dept. of Computer Science Fall 2013: August 22 CS 151: Object-Oriented Design © R. Mak 23 Iteration #2: Return Multiple Matching Guitars public List search(Guitar searchGuitar) { List matchingGuitars = new LinkedList(); for (Iterator iter = guitars.iterator(); iter.hasNext(); ) { Guitar guitar = (Guitar) iter.next(); // Ignore serial number since that's unique. // Ignore price since that's unique. if (searchGuitar.getBuilder() != guitar.getBuilder()) continue; String model = searchGuitar.getModel().toLowerCase(); if ((model != null) && (!model.equals("")) && (!model.equals(guitar.getModel().toLowerCase()))) continue; if (searchGuitar.getType() != guitar.getType()) continue; if (searchGuitar.getBackWood() != guitar.getBackWood()) continue; if (searchGuitar.getTopWood() != guitar.getTopWood()) continue; matchingGuitars.add(guitar); } return matchingGuitars; }

24. SJSU Dept. of Computer Science Fall 2013: August 22 CS 151: Object-Oriented Design © R. Mak 24 Still More Problems!  Customers don’t always know all the characteristics of the guitar they want. Need wildcard search fields?  Rick may decide to add more guitar characteristics to his inventory. Example: Number of guitar strings  The search() method of class Inventory is going to get complicated really fast. It will be difficult to maintain as more guitar characteristics are added. _

25. SJSU Dept. of Computer Science Fall 2013: August 22 CS 151: Object-Oriented Design © R. Mak 25 What’s Changing?  The characteristics of a guitar can change. Rick can decide to add, remove, or modify them.  The inventory keeps track of guitars, not guitar characteristics. Therefore, the inventory code should not change when the guitar characteristics change.  If we encapsulate what changes (guitar characteristics), we can isolate those changes from the rest of the code. Goal: When the guitar characteristics change, the rest of the code does not need to change. _

26. SJSU Dept. of Computer Science Fall 2013: August 22 CS 151: Object-Oriented Design © R. Mak 26 The Solution: Encapsulation  Create a new GuitarSpec class that represents the characteristics of a guitar. Only the GuitarSpec class needs to change if the characteristics change. Therefore, the GuitarSpec class encapsulates the changes and isolates them from the rest of the code. _

27. SJSU Dept. of Computer Science Fall 2013: August 22 CS 151: Object-Oriented Design © R. Mak 27 The New GuitarSpec Class public class GuitarSpec { private Builder builder; private String model; private Type type; private int numStrings; private Wood backWood; private Wood topWood; public GuitarSpec(Builder builder, String model, Type type, int numStrings, Wood backWood, Wood topWood) { this.builder = builder; this.model = model; this.type = type; this.numStrings = numStrings; this.backWood = backWood; this.topWood = topWood; } … public int getNumStrings() {return numStrings;} … }

28. SJSU Dept. of Computer Science Fall 2013: August 22 CS 151: Object-Oriented Design © R. Mak 28 Guitar - GuitarSpec Class Diagram  This UML class diagram shows that: A Guitar aggregates a GuitarSpec.  A GuitarSpec is part of a Guitar. The relationship is one-to-one. _ From: Head First Object-Oriented Analysis & Design, O’Reilly, 2006.

29. SJSU Dept. of Computer Science Fall 2013: August 22 CS 151: Object-Oriented Design © R. Mak 29 Updated Guitar Class public class Guitar { private String serialNumber; private double price; GuitarSpec spec; public Guitar(String serialNumber, double price, Builder builder, String model, Type type, Wood backWood, Wood topWood) { this.serialNumber = serialNumber; this.price = price; this.spec = new GuitarSpec(builder, model, type, backWood, topWood); } … public GuitarSpec getSpec() {return spec;} }

30. SJSU Dept. of Computer Science Fall 2013: August 22 CS 151: Object-Oriented Design © R. Mak 30 Time to Refactor Again!  Refactor: To modify the structure of your code without modifying its behavior in order to improve it in some way.  If the guitar characteristics change, such as adding the number of guitar strings, then the search method needs to change. The customer may want to search for a guitar that matches a certain number of strings. What do we need to do with code that changes?  We need to move the guitar matching algorithm out of the Inventory class (the search() method) and into the new GuitarSpec class in order to encapsulate the changes to the search method. _

31. SJSU Dept. of Computer Science Fall 2013: August 22 CS 151: Object-Oriented Design © R. Mak 31 Method matches() of Class GuitarSpec public class GuitarSpec { … public boolean matches(GuitarSpec otherSpec) { if (builder != otherSpec.builder) return false; if ((model != null) && (!model.equals("")) && (!model.toLowerCase().equals(otherSpec.model.toLowerCase()))) return false; if (type != otherSpec.type) return false; if (numStrings != otherSpec.numStrings) return false; if (backWood != otherSpec.backWood) return false; if (topWood != otherSpec.topWood) return false; return true; } … } This code was originally in the search() method of class Inventory.

32. SJSU Dept. of Computer Science Fall 2013: August 22 CS 151: Object-Oriented Design © R. Mak 32 Updated search() Method of Class Inventory public class Inventory {... public List search(GuitarSpec searchSpec) { List matchingGuitars = new LinkedList(); for (Iterator iter = guitars.iterator(); iter.hasNext(); ) { Guitar guitar = (Guitar) iter.next(); if (guitar.getSpec().matches(searchSpec)) { matchingGuitars.add(guitar); } } return matchingGuitars; }... } This code is a lot easier to read! Now the search() method delegates the matching algorithm to the matches() method of the GuitarSpec class.

33. SJSU Dept. of Computer Science Fall 2013: August 22 CS 151: Object-Oriented Design © R. Mak 33 Application Development Big Picture

34. SJSU Dept. of Computer Science Fall 2013: August 22 CS 151: Object-Oriented Design © R. Mak 34 Iterative Development

35. SJSU Dept. of Computer Science Fall 2013: August 22 CS 151: Object-Oriented Design © R. Mak 35 Incremental Development  Each iteration adds functionality to code that already works.  No Big Bang! _ Start Goal From: Head First Object-Oriented Analysis & Design, O’Reilly, 2006.