CS 151: Object-Oriented Design August 27 Class Meeting Department of Computer Science San Jose State...
-
Upload
maude-carson -
Category
Documents
-
view
216 -
download
2
Transcript of CS 151: Object-Oriented Design August 27 Class Meeting Department of Computer Science San Jose State...
CS 151: Object-Oriented DesignAugust 27 Class Meeting
Department of Computer ScienceSan Jose State University
Fall 2013Instructor: Ron Mak
www.cs.sjsu.edu/~mak
SJSU Dept. of Computer ScienceSpring 2013: August 27
CS 151: Object-Oriented Design© R. Mak
2
Key Points from Last Week on Good Design
There is no magic formula. Every good design is achieved after a journey.
It’s an iterative process. Start with a workable initial design. Each iteration builds upon working code to improve the design.
One good design technique: encapsulation. Encapsulate the code that will vary. Isolate the changes from the rest of the code. Encapsulation supports code reliability and flexibility (how?).
The design/code/test iterations are part of the overall “big picture” to develop a software application. No “big bang”!
SJSU Dept. of Computer ScienceSpring 2013: August 27
CS 151: Object-Oriented Design© R. Mak
3
Application Development Big Picture
SJSU Dept. of Computer ScienceSpring 2013: August 27
CS 151: Object-Oriented Design© R. Mak
4
Iterative Development
SJSU Dept. of Computer ScienceSpring 2013: August 27
CS 151: Object-Oriented Design© R. Mak
5
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.
SJSU Dept. of Computer ScienceSpring 2013: August 27
CS 151: Object-Oriented Design© R. Mak
6
Rick’s Guitar Application
What made us believe that this
is a good design?
From: Head First Object-Oriented Analysis & Design, O’Reilly, 2006.
SJSU Dept. of Computer ScienceSpring 2013: August 27
CS 151: Object-Oriented Design© R. Mak
7
A New Requirement!
Rick changes the name of his shop to Rick’s Music.
He adds mandolins to the type of instruments he sells.
How easily can our software design accommodate this change?
SJSU Dept. of Computer ScienceSpring 2013: August 27
CS 151: Object-Oriented Design© R. Mak
8
Possible Mandolin Solutions
Add a Mandolin class. Cut and paste code from the existing Guitar class.
Replace the Guitar class with an Instrument class. A type field indicates whether the instrument is a guitar or a mandolin.
Add a new Instrument class. Make the existing Guitar class and a new Mandolin class
subclasses of the Instrument class.
Mandolin class Simple to implement •Duplicate code•Hard to maintain
Instrument class with type field
No duplicate code •Not an O-O solution•Need to check type on objects
Solution Advantages Disadvantages
Instrument base class •O-O solution•No type field to check•No duplicate code
Does Rick have an Instrument in the inventory?
From: Head First Object-Oriented Analysis & Design, O’Reilly, 2006.
SJSU Dept. of Computer ScienceSpring 2013: August 27
CS 151: Object-Oriented Design© R. Mak
9
New Instrument Class
Add a new Instrument class. Make the existing Guitar class and a new Mandolin class
subclasses of the Instrument class.
Change the Inventory class to contain a list of Instrument objects instead of only Guitar objects. Each Instrument object can be either a Guitar object
or a Mandolin object.
It doesn’t make sense to create Instrument objects directly, only Guitar and Mandolin objects.
Therefore, make the Instrument class abstract. Make the Instrument class the abstract base class of the
Guitar and Mandolin subclasses._
SJSU Dept. of Computer ScienceSpring 2013: August 27
CS 151: Object-Oriented Design© R. Mak
10
Abstract Classes
An abstract class is a placeholder for the actual implementation classes.
The abstract class defines the behavior, and the subclasses implement that behavior.
The abstract class encapsulates shared behavior and defines the protocol for all its subclasses._
SJSU Dept. of Computer ScienceSpring 2013: August 27
CS 151: Object-Oriented Design© R. Mak
11
New InstrumentSpec Class
Add a new abstract InstrumentSpec class. Base class for the GuitarSpec and MandolinSpec
subclasses.
The Instrument class has a one-to-one association with the InstrumentSpec class._
SJSU Dept. of Computer ScienceSpring 2013: August 27
CS 151: Object-Oriented Design© R. Mak
12
Next Iteration Design
From: Head First Object-Oriented Analysis & Design, O’Reilly, 2006.
SJSU Dept. of Computer ScienceSpring 2013: August 27
CS 151: Object-Oriented Design© R. Mak
13
New Instrument Class
public abstract class Instrument { private String serialNumber; private double price; private InstrumentSpec spec;
public Instrument(String serialNumber, double price, InstrumentSpec spec) { this.serialNumber = serialNumber; this.price = price; this.spec = spec; }
public String getSerialNumber() { return serialNumber; } ... }
SJSU Dept. of Computer ScienceSpring 2013: August 27
CS 151: Object-Oriented Design© R. Mak
14
New InstrumentSpec Class
public abstract class InstrumentSpec { private Builder builder; private String model; private Type type; private Wood backWood; private Wood topWood;
public InstrumentSpec(Builder builder, String model, Type type, Wood backWood, Wood topWood) { this.builder = builder; this.model = model; this.type = type; this.backWood = backWood; this.topWood = topWood; }
...}
Common base class attributes.
SJSU Dept. of Computer ScienceSpring 2013: August 27
CS 151: Object-Oriented Design© R. Mak
15
New InstrumentSpec Class, cont’d
public boolean matches(InstrumentSpec otherSpec) { if (builder != otherSpec.builder) return false; if ((model != null) && (!model.equals("")) && (!model.equals(otherSpec.model))) return false; if (type != otherSpec.type) return false; if (backWood != otherSpec.backWood) return false; if (topWood != otherSpec.topWood) return false; return true; }
Match base class attributes only.
SJSU Dept. of Computer ScienceSpring 2013: August 27
CS 151: Object-Oriented Design© R. Mak
16
Revised Inventory Classpublic class Inventory { private List inventory; ...
public void addInstrument(String serialNumber, double price, InstrumentSpec spec) { Instrument instrument = null; if (spec instanceof GuitarSpec) { instrument = new Guitar(serialNumber, price, (GuitarSpec) spec); } else if (spec instanceof MandolinSpec) { instrument = new Mandolin(serialNumber, price, (MandolinSpec) spec); } inventory.add(instrument); }}
SJSU Dept. of Computer ScienceSpring 2013: August 27
CS 151: Object-Oriented Design© R. Mak
17
Revised Inventory Class, cont’d
public List search(GuitarSpec searchSpec) { List matchingGuitars = new LinkedList(); for (Iterator i = inventory.iterator(); i.hasNext();) { Guitar guitar = (Guitar) i.next(); if (guitar.getSpec().matches(searchSpec)) { matchingGuitars.add(guitar); } } return matchingGuitars; }
public List search(MandolinSpec searchSpec) { List matchingMandolins = new LinkedList(); for (Iterator i = inventory.iterator(); i.hasNext();) { Mandolin mandolin = (Mandolin) i.next(); if (mandolin.getSpec().matches(searchSpec)) { matchingMandolins.add(mandolin); } } return matchingMandolins; }
Search for guitars.
Search for mandolins.
Overloaded search() methods.
SJSU Dept. of Computer ScienceSpring 2013: August 27
CS 151: Object-Oriented Design© R. Mak
18
Guitar and Mandolin Classes
public class Guitar extends Instrument{ public Guitar(String serialNumber, double price, GuitarSpec spec) { super(serialNumber, price, spec); }}
public class Mandolin extends Instrument { public Mandolin(String serialNumber, double price, MandolinSpec spec) { super(serialNumber, price, spec); }}
What’s the differencebetween these two classes?
SJSU Dept. of Computer ScienceSpring 2013: August 27
CS 151: Object-Oriented Design© R. Mak
19
Revised GuitarSpec Classpublic class GuitarSpec extends InstrumentSpec { private int numStrings; ...
// Override the superclass matches() public boolean matches(InstrumentSpec otherSpec) { if (!super.matches(otherSpec)) return false;
if (!(otherSpec instanceof GuitarSpec)) return false;
GuitarSpec spec = (GuitarSpec) otherSpec; if (numStrings != spec.numStrings) return false; return true; }}
Match base class attributes.
SJSU Dept. of Computer ScienceSpring 2013: August 27
CS 151: Object-Oriented Design© R. Mak
20
New MandolinSpec Classpublic class MandolinSpec extends InstrumentSpec { private Style style; ...
// Override the superclass matches() public boolean matches(InstrumentSpec otherSpec) { if (!super.matches(otherSpec)) return false;
if (!(otherSpec instanceof MandolinSpec)) return false;
MandolinSpec spec = (MandolinSpec) otherSpec; if (!style.equals(spec.style)) return false; return true; }}
Match base class attributes.
What’s the difference betweenthe two matches() methods?
SJSU Dept. of Computer ScienceSpring 2013: August 27
CS 151: Object-Oriented Design© R. Mak
21
Take roll!
SJSU Dept. of Computer ScienceSpring 2013: August 27
CS 151: Object-Oriented Design© R. Mak
22
Any Red Flags?
Duplicated code Guitar and Mandolin classes GuitarSpec and MandolinSpec classes
Overloaded search() methods in class Inventory: public List search(GuitarSpec searchSpec) { List matchingGuitars = new LinkedList(); for (Iterator i = inventory.iterator(); i.hasNext();) { Guitar guitar = (Guitar) i.next(); if (guitar.getSpec().matches(searchSpec)) { matchingGuitars.add(guitar); } } return matchingGuitars; }
public List search(MandolinSpec searchSpec) { List matchingMandolins = new LinkedList(); for (Iterator i = inventory.iterator(); i.hasNext();) { Mandolin mandolin = (Mandolin) i.next(); if (mandolin.getSpec().matches(searchSpec)) { matchingMandolins.add(mandolin); } } return matchingMandolins; }
SJSU Dept. of Computer ScienceSpring 2013: August 27
CS 151: Object-Oriented Design© R. Mak
23
More Red Flags?
Serial type tests, such as in method addInstrument() in class Inventory:
public void addInstrument(String serialNumber, double price, InstrumentSpec spec) { Instrument instrument = null; if (spec instanceof GuitarSpec) { instrument = new Guitar(serialNumber, price, (GuitarSpec) spec); } else if (spec instanceof MandolinSpec) { instrument = new Mandolin(serialNumber, price, (MandolinSpec) spec); } inventory.add(instrument); }
SJSU Dept. of Computer ScienceSpring 2013: August 27
CS 151: Object-Oriented Design© R. Mak
24
Rick Wants More Instruments!
YIKES!Our design doesn’tscale very well ...
From: Head First Object-Oriented Analysis & Design, O’Reilly, 2006.
SJSU Dept. of Computer ScienceSpring 2013: August 27
CS 151: Object-Oriented Design© R. Mak
25
Our Design Doesn’t Scale Very Well
For each new instrument:
We need to add a subclass of Instrument. We need to add a subclass of InstrumentSpec.
In class Inventory, we need to add: a new search() method a new type test in the addInstrument() method
_
SJSU Dept. of Computer ScienceSpring 2013: August 27
CS 151: Object-Oriented Design© R. Mak
26
Time to Revisit Our Design!
Having all those Instrument and InstrumentSpec subtypes may not be such a good idea after all.
What varies among the instrument classes? properties matching algorithm
What doesn’t vary? manufacturer type price serial number
What should we do withstuff that varies?
SJSU Dept. of Computer ScienceSpring 2013: August 27
CS 151: Object-Oriented Design© R. Mak
27
Encapsulation to the Rescue!
If we can encapsulate the varying instrument properties in one place ... We can get rid of all the Instrument and InstrumentSpec
subclasses. Then both the Instrument and InstrumentSpec classes
can become concrete classes (instead of being abstract).
Instrument properties vary across the instrument types. A guitar has some different properties than mandolins.
Encapsulate the varying properties in a hash table. property name : property value pairs Each type of instrument can have a different set of properties.
_
SJSU Dept. of Computer ScienceSpring 2013: August 27
CS 151: Object-Oriented Design© R. Mak
28
Revised InstrumentSpec Class
public class InstrumentSpec { private Map properties;
public InstrumentSpec(Map properties) { if (properties == null) { this.properties = new HashMap(); } else { this.properties = new HashMap(properties); } }
...
SJSU Dept. of Computer ScienceSpring 2013: August 27
CS 151: Object-Oriented Design© R. Mak
29
Revised InstrumentSpec Class, cont’d
public boolean matches(InstrumentSpec otherSpec) { // Loop over the property keys in the hashmap. for (Iterator i = otherSpec.getProperties().keySet().iterator(); i.hasNext();) { // Do all the properties match? String propertyName = (String) i.next(); if (!properties.get(propertyName) .equals(otherSpec.getProperty(propertyName))) { return false; } }
return true;} This is a generic matching algorithm that works
with any instrument type’s properties.
SJSU Dept. of Computer ScienceSpring 2013: August 27
CS 151: Object-Oriented Design© R. Mak
30
Re-revised Inventory Class
public class Inventory { private List inventory;
...
public void addInstrument(String serialNumber, double price, InstrumentSpec spec) { Instrument instrument = new Instrument(serialNumber, price, spec); inventory.add(instrument); }
...
SJSU Dept. of Computer ScienceSpring 2013: August 27
CS 151: Object-Oriented Design© R. Mak
31
Re-revised Inventory Class, cont’d
public List search(InstrumentSpec searchSpec) { List matchingInstruments = new LinkedList();
for (Iterator i = inventory.iterator(); i.hasNext();) { Instrument instrument = (Instrument) i.next();
if (instrument.getSpec().matches(searchSpec)) { matchingInstruments.add(instrument); } }
return matchingInstruments; }}
Only one search() method needed!
SJSU Dept. of Computer ScienceSpring 2013: August 27
CS 151: Object-Oriented Design© R. Mak
32
Improved Design
From: Head First Object-Oriented Analysis & Design, O’Reilly, 2006.
SJSU Dept. of Computer ScienceSpring 2013: August 27
CS 151: Object-Oriented Design© R. Mak
33
Improved Design, cont’d
From: Head First Object-Oriented Analysis & Design, O’Reilly, 2006.
SJSU Dept. of Computer ScienceSpring 2013: August 27
CS 151: Object-Oriented Design© R. Mak
34
Conclusions
It takes a journey to achieve Good Design iterative improvements wrong paths backtracking
Developing Great Software can be a messy business! Be willing to fix your own bad design decisions.
_