CS 151: Object-Oriented Design August 22 Class Meeting Department of Computer Science San Jose State University Fall 2013 Instructor: Ron Mak mak

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



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 _



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.



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



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

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

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

Take roll!



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?

_



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

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

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

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!

_



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

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?



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

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

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

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

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

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?



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



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

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

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

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

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.

_




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



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

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.



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.



33

Application Development Big Picture



34

Iterative Development



35

Incremental Development

Each iteration adds functionality to code that already works.

No Big Bang!_

Start

Goal


Documents

CS 151: Object-Oriented Design August 22 Class Meeting Department of Computer Science San Jose State University Fall 2013 Instructor: Ron Mak mak