10-gooddesignflexiblesoftwa

10-gooddesignflexiblesoftwa - Good Design == Flexible...

Info iconThis preview shows pages 1–7. Sign up to view the full content.

View Full Document Right Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Good Design == Flexible Software (Part 2) Kenneth M. Anderson University of Colorado, Boulder CSCI 4448/5448 Lecture 10 09/24/2009 University of Colorado, 2009 1 Lecture Goals Review material from Chapter 5, part 2, of the OO A&D textbook Good Design == Flexible Software How to achieve exible software The Importance of Iteration The Great Ease-Of-Change Challenge Cohesive Classes Discuss the Chapter 5 Example: Ricks Guitars, Revisited Emphasize the OO concepts and techniques encountered in Chapter 5 2 Review: Our Three (Most Recent) OO Principles Code to an Interface If you have a choice between coding to an interface or an abstract base class as opposed to an implementation or subclass, choose the former Let polymorphism be your friend Encapsulate What Varies Find the locations of your software likely to change and wrap them inside a class; hide the details of what can change behind the public interface of the class Only One Reason To Change Each class should have only one reason that can cause it to change (the thing it encapsulates) 3 Ricks Current Application 4 getBuilder(): Builder getModel(): String getType(): Type getBackWood(): Wood getTopWood(): Wood matches(InstrumentSpec): boolean model: String InstrumentSpec Builder Type Wood builder topWood backWood type getStyle(): Style matches(InstrumentSpec): boolean MandolinSpec Style style getNumStrings(): int matches(InstrumentSpec): boolean numStrings: int GuitarSpec Guitar Mandolin getSerialNumber(): String getPrice(): double setPrice(double) getSpec(): InstrumentSpec serialNumber: String price: double Instrument spec addInstrument(String, double, InstrumentSpec) get(Sring): Instrument search(GuitarSpec): Guitar [*] search(MandolinSpec): Mandolin [*] Inventory inventory * The Problems? Inventory.addInstrument() has code specifc to each instrument type IF we add a new Instrument subclass, we have to change this method. The Inventory class has one search() method For each type oF instrument InstrumentSpec is an abstract class and we cant instantiate it directly. This means that we cant search across instruments easily Instrument subclasses dont oFFer much Functionality Instrument does all the hard work. Each time we add a new subclass to Instrument, we need to add a new subclass to InstrumentSpec 5 search() Upgrade We start by looking at the problem of having multiple search() methods one for each subclass of InstrumentSpec This situation is simply not tenable our system will never be Fexible if we have to change Inventorys public interface every time we want to add a new type of Instrument to our system!...
View Full Document

Page1 / 33

10-gooddesignflexiblesoftwa - Good Design == Flexible...

This preview shows document pages 1 - 7. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online