CS 151: Object-Oriented DesignAugust 22 Class Meeting
Department of Computer ScienceSan Jose State University
Fall 2013Instructor: Ron Mak
www.cs.sjsu.edu/~mak
SJSU Dept. of Computer ScienceFall 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. _
SJSU Dept. of Computer ScienceFall 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, 2nd editionby Cay Horstmann _
SJSU Dept. of Computer ScienceFall 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 quizzesduring some classes.
SJSU Dept. of Computer ScienceFall 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: [email protected] _
SJSU Dept. of Computer ScienceFall 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.
SJSU Dept. of Computer ScienceFall 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. _
SJSU Dept. of Computer ScienceFall 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._
SJSU Dept. of Computer ScienceFall 2013: August 22
CS 151: Object-Oriented Design© R. Mak
9
Take roll!
SJSU Dept. of Computer ScienceFall 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 beObject-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?
_
SJSU Dept. of Computer ScienceFall 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!
_
SJSU Dept. of Computer ScienceFall 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
_
SJSU Dept. of Computer ScienceFall 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.
_
SJSU Dept. of Computer ScienceFall 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 iterativelyas 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!
_
SJSU Dept. of Computer ScienceFall 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.
SJSU Dept. of Computer ScienceFall 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
Whyprivate?
SJSU Dept. of Computer ScienceFall 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
SJSU Dept. of Computer ScienceFall 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); }
...}
SJSU Dept. of Computer ScienceFall 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;}
SJSU Dept. of Computer ScienceFall 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;}
SJSU Dept. of Computer ScienceFall 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.
_
SJSU Dept. of Computer ScienceFall 2013: August 22
CS 151: Object-Oriented Design© R. Mak
22
Iteration #1: Remove String Fieldspublic 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?
SJSU Dept. of Computer ScienceFall 2013: August 22
CS 151: Object-Oriented Design© R. Mak
23
Iteration #2: Return Multiple Matching Guitarspublic 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;}
SJSU Dept. of Computer ScienceFall 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._
SJSU Dept. of Computer ScienceFall 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._
SJSU Dept. of Computer ScienceFall 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._
SJSU Dept. of Computer ScienceFall 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;} …}
SJSU Dept. of Computer ScienceFall 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.
SJSU Dept. of Computer ScienceFall 2013: August 22
CS 151: Object-Oriented Design© R. Mak
29
Updated Guitar Classpublic 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;}}
SJSU Dept. of Computer ScienceFall 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._
SJSU Dept. of Computer ScienceFall 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 originallyin the search() methodof class Inventory.
SJSU Dept. of Computer ScienceFall 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() methoddelegates the matching
algorithm to the matches()method of the GuitarSpec class.
SJSU Dept. of Computer ScienceFall 2013: August 22
CS 151: Object-Oriented Design© R. Mak
33
Application Development Big Picture
SJSU Dept. of Computer ScienceFall 2013: August 22
CS 151: Object-Oriented Design© R. Mak
34
Iterative Development
Top Related