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

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”!



3

Application Development Big Picture



4

Iterative Development



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.



6

Rick’s Guitar Application

What made us believe that this

is a good design?




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?



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?




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



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



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



12

Next Iteration Design




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



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.



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.



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



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.



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?



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.



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?



21

Take roll!



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



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



24

Rick Wants More Instruments!

YIKES!Our design doesn’tscale very well ...




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

_



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?



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.

_



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

...



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.



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

...



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!



32

Improved Design




33

Improved Design, cont’d




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.

_

Documents

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