CS 151: Object-Oriented Design August 27 Class Meeting Department of Computer Science San Jose State...

Preview:

Citation preview

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.

_

Recommended