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

SJSU Dept. of Computer Science Spring 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 Science Spring 2013: August 27 CS 151: Object-Oriented Design © R. Mak 3 Application Development Big Picture

SJSU Dept. of Computer Science Spring 2013: August 27 CS 151: Object-Oriented Design © R. Mak 4 Iterative Development

SJSU Dept. of Computer Science Spring 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 Science Spring 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 Science Spring 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 Science Spring 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 classSimple to implementDuplicate code Hard to maintain Instrument class with type field No duplicate codeNot an O-O solution Need to check type on objects SolutionAdvantagesDisadvantages Instrument base classO-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 Science Spring 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 Science Spring 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 Science Spring 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 Science Spring 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 Science Spring 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 Science Spring 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 Science Spring 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 Science Spring 2013: August 27 CS 151: Object-Oriented Design © R. Mak 16 Revised Inventory Class public 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 Science Spring 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 Science Spring 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 difference between these two classes?

SJSU Dept. of Computer Science Spring 2013: August 27 CS 151: Object-Oriented Design © R. Mak 19 Revised GuitarSpec Class public 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 Science Spring 2013: August 27 CS 151: Object-Oriented Design © R. Mak 20 New MandolinSpec Class public 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 between the two matches() methods?

SJSU Dept. of Computer Science Spring 2013: August 27 CS 151: Object-Oriented Design © R. Mak 21 Take roll!

SJSU Dept. of Computer Science Spring 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 Science Spring 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 Science Spring 2013: August 27 CS 151: Object-Oriented Design © R. Mak 24 Rick Wants More Instruments! YIKES! Our design doesn’t scale very well... From: Head First Object-Oriented Analysis & Design, O’Reilly, 2006.

SJSU Dept. of Computer Science Spring 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 Science Spring 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 with stuff that varies?

SJSU Dept. of Computer Science Spring 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 Science Spring 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 Science Spring 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 Science Spring 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 Science Spring 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 Science Spring 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 Science Spring 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 Science Spring 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. _